Les e-mails en mode sombre

Les messageries repeignent les e-mails en mode sombre, et elles ne sont pas d'accord sur la manière. Le produit ne vous donne pas de thème sombre — il vous donne une garantie négative : aucun texte sombre ne finit sur un fond sombre, et aucun texte clair sur un fond clair. En dehors de ce cas, votre palette reste exactement telle que vous l'avez écrite. Une section que vous avez volontairement rendue sombre reste sombre.

Où la correction a lieu

Au moment du rendu, et de façon identique pour les cinq : un envoi de campagne, un envoi de séquence, un envoi de test, l'aperçu de l'éditeur et un rendu demandé par l'API. Deux conséquences. Les modèles et les campagnes enregistrés il y a longtemps en profitent sans être touchés — le HTML est rendu quand il est envoyé, pas quand il est écrit. Et rien n'a besoin d'être corrigé modèle par modèle.

Ce qu'elle fait à votre document

  • Un bloc @media (prefers-color-scheme: dark) est injecté, avec des déclarations !important, pour qu'il puisse l'emporter sur vos styles en ligne sans que le produit ait à analyser votre HTML.
  • Outlook.com est traité par ses propres crochets ([data-ogsc], [data-ogsb]), qu'il substitue aux classes en mode sombre.
  • Gmail ignore complètement prefers-color-scheme et applique sa propre inversion partielle. Il est couvert autrement : tout élément portant un fond reçoit une couleur de texte explicite.
  • Les balises meta color-scheme et supported-color-schemes sont ajoutées seulement quand les règles sombres les accompagnent — et retirées quand elles ne le peuvent pas.
Ce dernier point résume toute l'histoire du mode sombre. Déclarer color-scheme dit à la messagerie « je gère le sombre » : elle cesse donc d'appliquer sa propre inversion, qui au moins inversait le fond et le texte ensemble. Sans rien derrière la promesse, le fond s'assombrit et le texte reste noir. La déclaration seule est pire que rien.
Un !important en ligne met votre document hors de portée. Une règle dans un bloc <style> l'emporte sur un style en ligne — mais pas sur un style en ligne lui-même !important. Face à style="background-color:#ffffff !important", la correction perd : le fond reste blanc pendant que le texte s'éclaircit. Retirez le !important de vos couleurs en ligne.

Elle avertit, elle ne bloque jamais

Quand le moteur de rendu trouve une paire à risque, il la corrige et le signale. Aucun envoi n'est jamais refusé pour une question de contraste. Trois avis existent : le contraste a été corrigé, il n'a pas pu être vérifié, ou une déclaration color-scheme a été retirée parce que les règles qui devaient l'accompagner n'ont pas pu être produites.

Ce que cela implique ailleurs

L'aperçu de l'éditeur a une vue claire et une vue sombre — servez-vous-en. Voir le défaut avant l'envoi vaut plus que la correction elle-même. Les images ne sont pas couvertes : un logo figé sur du blanc reste sur du blanc pendant que tout ce qui l'entoure s'inverse. Utilisez un PNG transparent, ou une image lisible sur les deux fonds. Voir médias.