Parce que j’aime l’expéditeur et les sujets de cette newsletter, principalement : Biodéchets, énergies renouvelables, tri, consommation responsable… Que des thématiques qui me tiennent à cœur, et qui vont dans le sens des valeurs de Badsender !
Pour autant, je vais tout de même me permettre de passer un peu de temps ici sur un phrase mentionnée tout en bas de la newsletter : « Cette newsletter a été pensée et développée avec un objectif d’éco-conception. » Ça semble logique au regard de l’expéditeur. Mais lorsqu’on s’avance sur une telle affirmation, on peut aussi s’attendre à ce qu’un œil curieux et mesquin s’amuse à s’en assurer. Pof ! Me voici ! 🙂
L’éco-conception dans l’emailing se caractérise par un ensemble de critères à respecter, qui passent par : la fréquence d’envoi, l’entretien de sa liste de diffusion, le design, le code… Et c’est sur ce dernier point précisément que je compte m’attarder. Je ne mentionnerai que le poids en premier lieu de l’email : 105ko, une fois le code indenté. C’est tout de même assez conséquent. Et, en analysant le code, on comprend vite pourquoi :
- L’email semble avoir été conçu depuis le framework mjml, qui, comme tout framework, ajoute des
classet éléments de structure HTML qui ne sont pas « nécessaires » ou indispensables en toute fin. Ainsi, on retrouvera desclassinutilisées dans l’attribut html<style>, ou la présence d’attributsclassinutiles dans le<body>. - Il est fait appel à une typographie non web-safe, l’Ubuntu : il est dommage de ne pas se contenter de typos websafe, non ? Pourquoi ajouter une ressource supplémentaire ?
- Je note une utilisation à la fois de la propriété CSS
widthet de l’attribut htmlwidthdans certains morceaux de code : quelle en est l’utilité ? Surtout lorsqu’on sait qu’il est préférable, pour corriger les problèmes de rendu d’email sur Outlook en 120DPI, de n’utiliser que la propriété CSS. - Toujours dû à l’utilisation du framework : la présence de
<table>à chaque fois qu’on veut créer un nouveau bloc. Je pense qu’on pourrait en diminuer légèrement le nombre. - Un truc que je ne comprends pas trop : la présence de la propriété CSS raccourcie
paddingavec pour valeur10px 25px, et, juste à côté, l’ajout des propriétés CSSpadding-rightetpadding-left. Pourquoi ? - Des propriétés CSS comme
vertical-alignqui traînent sur des cellules (<td>) qui n’ont pas de cellules sœurs. Je ne comprends pas non plus… - Je vois la propriété CSS
cursoravec la valeurautosur des éléments comme des<td>utilisées pour créer des appels à l’action : y a-t-il une raison particulière à cela ? Il y aurait des environnements d’ouverture où le comportement de la souris au survol sur un lien serait différent ? - Des tableaux imbriqués dans des tableaux pour un simple titre ou une simple image… Autant j’aime la technique de codage Hybrid/Fluid, autant j’aime aussi qu’elle est utilisée correctement et sans surcharge du code !
- Pour certains textes/tags, la propriété CSS
text-transformest appelée avec la valeuruppercase… Mais le texte est déjà en majuscules ! Là, c’est du code gâché… - Des cellules vides utilisées pour générer des bordures, ça je ne suis vraiment pas fan. Surtout que la bordure elle-même est correctement définie avec la propriété CSS
border-left. Alors pourquoi ajouter une cellule pour cela ? Pourquoi ne pas appliquer la propriété CSS directement sur la cellule comprenant le texte ?
En revanche, je note que des points d’optimisation pour l’accessibilité ne sont pas intégrés, comme l’utilisation de balises sémantiques, l’ajout d’un texte dans la balise <title> de l’email, l’absence de la <div role="article" [...]> juste après l’ouverture du <body>…. C’est très bien de vouloir faire une newsletter éco-conçue, mais c’est tout aussi bien, pour un organisme d’État, que de penser à l’accessibilité de ses supports de communication, non ?
Voilà allez, j’arrête là : il s’agit d’un exemple d’email hein, pas d’un article complet ! 😉