Caniemail.com - service de vérification de compatibilité des contenus d’e-mail (version e-mail de caniuse)

Prise en charge de la propriété CSS transition (29 mars 2024)

• Récapitulatif de la prise en charge de la propriété CSS transition dans les clients e-mail
• La propriété CSS transition permet d’animer les changements de valeurs des propriétés CSS sur une durée donnée
• Elle n’est pas encore largement prise en charge par les clients e-mail

Prise en charge de la propriété CSS text-wrap (3 avril 2024)

• Récapitulatif de la prise en charge de la propriété CSS text-wrap dans les clients e-mail
• La propriété CSS text-wrap permet de définir comment les mots longs doivent être coupés à la ligne
• Elle n’est pas encore largement prise en charge par les clients e-mail

Prise en charge des propriétés CSS word-spacing, shape-margin, shape-outside (13 mars 2024)

• Récapitulatif de la prise en charge des propriétés CSS word-spacing, shape-margin, shape-outside dans les clients e-mail
• word-spacing est une propriété qui permet d’ajuster l’espacement entre les mots
• shape-margin et shape-outside sont des propriétés qui définissent la manière dont le texte s’habille autour d’une image ou d’un objet
• Elles ne sont pas encore largement prises en charge par les clients e-mail

Actualités des mises à jour Caniemail de mars 2024 (29 mars 2024)

• Informations récapitulatives sur les mises à jour ajoutées au site Caniemail en mars 2024

Actualités des mises à jour Caniemail de février 2024 (29 février 2024)

• Informations récapitulatives sur les mises à jour ajoutées au site Caniemail en février 2024

État de la prise en charge des propriétés CSS par les clients e-mail

• Apple Mail (macOS) : 267 prises en charge sur 284
• Apple Mail (iOS) : 266 prises en charge sur 284
• Samsung Email (Android) : 239 prises en charge sur 284
• SFR (webmail desktop) : 226 prises en charge sur 257
• WEB.DE (iOS) : 222 prises en charge sur 235

Présentation du site Caniemail

• Site lancé et maintenu par @HTeuMeuLeu et l’équipe de Tilt Studio
• Basé sur le site caniuse.com original de @Fyrd et designé par @Lensco
• Basé sur l’idée originale et le nom proposés par @M_J_Robbins et l’équipe Rebel
• La communauté des développeurs e-mail sur GitHub contribue aux données
• En cas de problème, le site invite à signaler les bugs sur GitHub

L’avis de GN⁺

• Un site très utile pour les développeurs e-mail, qui permet de voir d’un coup d’œil la prise en charge des propriétés CSS selon chaque client e-mail. C’est un site indispensable pour vérifier la compatibilité lorsqu’on applique de nouvelles propriétés CSS aux e-mails.
• La prise en charge de CSS par les clients e-mail reste encore très insuffisante par rapport aux navigateurs web. Les propriétés liées à l’animation ou à la mise en page sont presque totalement absentes, ce qui constitue une limite pour le design d’e-mails.
• Le site publie régulièrement des informations de mise à jour, ce qui semble utile aux développeurs e-mail pour rester à jour. En revanche, le rythme des mises à jour est si soutenu qu’il peut être difficile à suivre.
• Parmi les sites similaires, on peut citer EmailOnAcid et Litmus, qui se distinguent en proposant des captures d’écran d’aperçu du rendu dans chaque client. Utilisés avec Caniemail, ils peuvent produire un effet de synergie.

[GN⁺]

Commentaires sur Hacker News

• Excellente ressource, et Outlook est vraiment pénible avec son support très limité
  J’avais souvent du mal en créant des templates d’e-mails pour les notifications de l’app de l’entreprise, puis je suis passé à MJML(https://mjml.io/) et ça s’est beaucoup mieux passé
  Parmi les différents appareils testés, c’était ce qui semblait offrir la meilleure compatibilité, et j’utilisais Litmus(https://litmus.com) pour vérifier le rendu dans diverses apps et sur différents appareils. J’ai aussi essayé https://testi.at/ mentionné dans un autre fil, et ça marchait bien

  • MJML a l’air intéressant. J’aimerais qu’il y ait des raisons business poussant les organisations à se soucier d’e-mails accessibles et lisibles par machine
    Les e-mails HTML sont figés comme le web à l’époque d’IE6, donc pour les rares travaux e-mail qui demandent plus qu’une liste de balises image, j’ai utilisé Foundation for Emails(https://get.foundation/emails.html) et je suis déjà reconnaissant que ça existe
  • MJML est de loin le meilleur outil du domaine et je l’utilise souvent. Si vous créez des e-mails en 2024, c’est un raccourci essentiel pour éviter ou réduire les gros casse-tête des e-mails HTML
  • Je recommande aussi react-email(https://react.email) pour produire des e-mails. Les composants fournis sont suffisants, et c’est bien mieux que l’époque du marketing e-mail où on fabriquait des messages en ajoutant une balise toutes les cinq lignes
  • On dirait qu’aujourd’hui Outlook est l’Internet Explorer des clients mail

• Il y a une anecdote amusante à propos de ce site. Son opérateur disait avoir vu dans les logs d’utilisation beaucoup de traces de personnes qui avaient mal compris l’objectif du site, y saisissaient des noms de célébrités et tentaient de leur envoyer des e-mails

  • Au début, j’ai essayé de comprendre ce que c’était, mais je n’ai trouvé aucune vraie explication. C’est présenté comme un « caniuse pour le contenu des e-mails », mais si on ne sait pas ce qu’est caniuse, ce n’est pas facile à comprendre
    Avant de lancer un nouveau service, ce serait bien d’ajouter une courte section explicative pour qu’une personne moyenne puisse comprendre de quoi il s’agit

• Plus le score est bas, mieux c’est. Je connais pas mal de gens dont la politique est : « les e-mails n’autorisent que le texte brut, pas de pièces jointes sans accord préalable, et tout le reste est supprimé automatiquement »

  • Une légère extension du texte brut est raisonnable. Ce n’est pas qu’une question de décoration : pour les langues écrites de droite à gauche, les listes ou les liens, un peu de balisage aide, et le HTML suffit
    Le problème, c’est l’usage excessif de CSS, ou pire, le fait d’autoriser JavaScript. Je ne vois pas de problème de sécurité propre aux e-mails qui viendrait du HTML seul, sans CSS ni JavaScript
  • Je connais au moins deux personnes qui envoient des e-mails où la version HTML est vide ou dit seulement « n’utilisez pas de client boursouflé », tandis que le vrai contenu se trouve dans la version de secours en texte brut
    Il me semble qu’avec Thunderbird, il fallait afficher la source du message pour le lire

• Liens associés :
  Can I Email? - https://news.ycombinator.com/item?id=27112960 - mai 2021, 273 commentaires
  Can I Email: ‘Can I Use’ for email - https://news.ycombinator.com/item?id=20948826 - septembre 2019, 196 commentaires
  'Can I Use' for Email - https://news.ycombinator.com/item?id=20934601 - septembre 2019, 1 commentaire

• Les deux clients les plus populaires, Gmail et Outlook, sont respectivement 25e et 41e, donc tout en bas du classement

  • Parmi les fonctionnalités non prises en charge par Gmail, on trouve des choses comme display: none, les animations et d’autres propriétés CSS qu’on ne peut pas forcément considérer comme indispensables dans un e-mail
    Les bases sont assurées, donc viser un rang élevé n’est pas nécessairement un bon objectif
  • Ça me rappelle Internet Explorer, très populaire mais pauvre en fonctionnalités

• Un « document » HTML pleinement fonctionnel est en réalité plus proche d’une application que d’un document, donc il est logique que les clients mail limitent la prise en charge
  Mais à cause de cette fragmentation, j’aimerais qu’il existe un vrai standard. Il faudrait un sous-ensemble officiel de HTML non applicatif, incapable de charger des ressources distantes ou d’exécuter du code. Un format de document avec médias intégrés, animations, style, etc., suffirait

  • Peut-on encore appeler cela un « document » s’il contient des animations et des médias vidéo non statiques ?
  • Honnêtement, il n’y a aucune raison pour que d’autres puissent m’envoyer du code à exécuter ou des ressources à charger
    Je comprends que l’industrie de l’ad tech veuille transformer mon e-mail en panneau publicitaire, mais j’aimerais bien que ça cesse. Texte brut et pièces jointes suffisent

• Pour info, jsx-email intègre une fonctionnalité CLI de vérification de compatibilité des clients mail qui utilise le jeu de données caniemail : https://jsx.email/docs/core/cli#check

• Il serait probablement plus utile de lister uniquement les quelques propriétés CSS reconnues par tous les clients mail. Je ne plaisante pas, je le pense vraiment
  En général, la réponse de CanIEmail? est « non »

  • En sélectionnant « check all » sur https://www.caniemail.com/clients/, on peut voir séparément les fonctionnalités prises en charge par tous les clients mail et celles dont le support varie
    Parmi celles prises en charge partout, il semble y avoir à peu près border-collapse, la forme abrégée font, list-style-type, plusieurs unités CSS (cm, em, ex, in, mm, pc, %, pt, px), vertical-align, certains éléments HTML et l’attribut valign, ainsi que les formats d’image JPG/PNG

• Au début, j’ai cru que c’était un site gag affichant juste « No. » en gros

  • C’est généralement aussi ma réponse par défaut quand l’équipe design me demande de mettre à jour des templates d’e-mails. « Non. Mise en forme de base uniquement. Si vous voulez être un peu audacieux, peut-être des tableaux. Au-delà, non »

• La prise en charge du mode sombre dans les e-mails fait partie des choses les plus frustrantes que j’aie vécues comme développeur front-end depuis l’époque d’IE6
  En gros, on n’a d’autre choix que d’implémenter un design en mode clair, puis de choisir des couleurs qui resteront acceptables quand des clients mail maladroits en mode sombre inverseront automatiquement les couleurs
  Gmail est l’un des pires exemples. En mode sombre, il n’y a absolument aucun moyen de choisir soi-même les couleurs