Intégration HTML pour l’email : Support des jeux de graisse de caractère en CSS dans les emails

Partager sur facebook
Partager sur twitter
Partager sur linkedin
Partager sur email

integration-html-email(Test effectué sur les documents XHTML au Doctype 1.0 Transitionnal, HTML au Doctype 4.01 Transitionnal, XHTML au Doctype 1.0 Strict, HTML au Doctype 4.01 Strict, HTML5, et sans Doctype)

Au sein de votre e-mailing, il est bon de privilégier au maximum l’utilisation de textes bruts et de diminuer ainsi l’usage d’images. Cela permet non seulement d’améliorer la délivrabilité de votre e-mailing (cf. SpamAssassin HTML_IMAGE_RATIO_02) mais aussi de garantir un affichage optimisé en cas d’images bloquées ou non téléchargées par vos destinataires.

Et la mise en forme graphique des textes directement inclus dans votre code HTML passe, bien souvent, par des jeux de taille, de couleurs, de styles, ou de graisse !

C’est précisément ce dernier point que nous ciblerons dans les tests suivants. La question est la suivante : Parmi les multiples possibilités pour mettre un texte en exergue, lesquelles sont supportées par la plupart des webmails ? Mais aussi : L’usage de certaines balises peut-il jouer sur la délivrabilité de votre campagne ?

Voici, sans transition, les conclusions que nous avons pu tirer après tests effectués sur Email on Acid, et que nous vous laissons découvrir ici.

Les balises <strong> et <b>  permettent bien, et ce sur l’ensemble des webmails proposés par la plateforme d’Email Preview, de mettre en gras les textes souhaités. La balise <b>  n’étant pas dépréciée dans les spécifications HTML4 ou HTML5 peut donc être utilisée. Car sachez que si la balise <strong>  est, par défaut, affiché en gras aujourd’hui, elle pourrait tout aussi bien, demain, être affichée autrement. La balise <b> n’apporte aucun sens sémantique, mais la sémantique n’est pas encore prise en compte (au niveau des balises html) dans les emails aujourd’hui.

En revanche, ce que vous pourrez constater, c’est que les « jeux » de graisse (plus ou moins forts) ne sont pas pris en compte ! Ou plutôt, pas dans leur intégralité : car seules deux solutions sont possibles : caractère maigre, ou caractère gras. Oubliez donc les « bolder, lighter, font-weight :200 », etc. Les font-weight, différents de bold, ne sont pas supportées du tout d’ailleurs sur Lotus Notes 6.5, Lotus Notes 7.

SEULS : AOL Chrome (win), AOL IE9 (win), AOL IE10 (win), AOL IE11 (win), BlackBerry 9930, BOL Chrome (win), Comcast Chrome (win), EarthLink Chrome (win), Freenet.de Chrome (win), GMX Chrome (win), Gmail Chrome (win), Libero Chrome (win), Mail.ru Chrome (win), Office 365 Chrome (win), Office 365 IE9 (win), Office 365 IE10 (win), Office 365 IE11 (win), Orange Chrome (win), Outlook.com Chrome (win), Outlook.com IE9 (win), Outlook.com IE10 (win), Outlook.com IE11 (win), SFR.fr Chrome (win), T-Online.de Chrome (win), Terra Chrome (win), Web.de Chrome (win), Yahoo! Chrome (win), Yahoo ! IE10 (win), Yahoo ! IE11 (win), semblent supporter ces différences de font-weight (mais seulement pour les valeurs [800] et [900]).

Faut-il en conclure que seuls Chrome et IE, sous Windows, supportent le font-weight :[800] et font-weight :[900] ?

Conclusion

La mise en gras de textes HTML bruts au sein d’un e-mailing est possible au travers des balises <b>, <strong>  et de l’attribut style=”font-weight :bold ;”. Privilégiez cependant la balise <b>  ou l’attribut style, car gardez à l’esprit que la balise <strong>  peut, à tout moment, changer de mise en forme !

Remarque : Android 2.3 et Android 4.0.3 ne passent les textes de font-weight : [valeur] en gras qu’à partir de la valeur [700] (alors que les autres webmails l’autorisent dès la valeur [600]).

integration-html-email-support-gras

Partager sur facebook
Partager sur twitter
Partager sur linkedin
Partager sur email

Contactez l'auteur de l'article

Responses

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Newsletter