Discuter:Formats : newsletters au format texte brut par défaut

Citer | Répondre

Je pense que cette bonne pratique est discutable sur de nombreux points : Le premier argument (Permettre aux utilisateurs de consulter les newsletters quels que soient leurs outils.) est douteux : si les normes d'accessibilité sont respectées, il n'y a aucune différence à ce niveau entre un document HTML ou texte brut.

Si le souci n'est pas de tenir compte du public handicapé mais de satisfaire la préférence des 0,001% des utilisateurs qui utilisent un client email qui ne peut pas afficher un email HTML, on se trompe de solution. Tous les clients email que je connais peuvent retirer les balises des documents HTML et les présenter en format texte (même ceux utilisant un terminal pour interface, Mutt, etc).

Par conséquent, si le souci est d'afficher une version texte sans transformation, alors pourquoi ne pas systématiquement envoyer la newsletter au format MIME, avec un en-tête Content-Type: multipart/alternative;, puis inclure une version en Content-Type: text/plain, et une autre en Content-Type: text/html ? Personnellement, c'est ce que je fais, et je m'en suis toujours bien porté.

Le second argument (Limiter la charge des serveurs de messagerie électronique.) me semble un peu ridicule : alors qu'actuellement plus de 50% du traffic email est composé de spam et de virus, pourquoi vouloir économiser quelques Kb par envoi quand le bénéfice en terme de communication est très important ? De plus, il s'agit plus d'une pénalité de bande passante que de charge serveur. Et si le problème est une vraie pénurie de bande passante, ne pas inclure les images en attachement devrait résoudre le problème.

Je propose soit de supprimer purement et simplement cette bonne pratique, soit de la reformuler pour prendre en compte le souci légitime d'accessibilité de manière plus fine :

• soit les newsletters doivent utiliser du HTML accessible (c.f tout ce qui a déjà été dit sur le sujet),
• soit les newsletters doivent contenir aussi une version en text/plain.

Personnellement, je penche pour la seconde option, parce que j'ai un faible pour le ASCII Art :), et aussi parce que les disparités d'affichage dans les clients email actuels obligent souvent à utiliser une soupe de tags épouvantable (rebonjour <font>, etc).