Caniemail.com - Dienst zur Prüfung der Kompatibilität von E-Mail-Inhalten (caniuse-Version für E-Mails)

Unterstützung der CSS-Eigenschaft transition (29. März 2024)

• Eine Übersicht über den Stand der Unterstützung der CSS-Eigenschaft transition in E-Mail-Clients
• Die CSS-Eigenschaft transition ermöglicht es, Änderungen von CSS-Eigenschaftswerten über einen bestimmten Zeitraum mit Animationseffekten zu versehen
• Wird von E-Mail-Clients noch nicht breit unterstützt

Unterstützung der CSS-Eigenschaft text-wrap (3. April 2024)

• Eine Übersicht über den Stand der Unterstützung der CSS-Eigenschaft text-wrap in E-Mail-Clients
• Die CSS-Eigenschaft text-wrap legt fest, wie lange Wörter umgebrochen werden sollen
• Wird von E-Mail-Clients noch nicht breit unterstützt

Unterstützung der CSS-Eigenschaften word-spacing, shape-margin, shape-outside (13. März 2024)

• Eine Übersicht über den Stand der Unterstützung der CSS-Eigenschaften word-spacing, shape-margin, shape-outside in E-Mail-Clients
• word-spacing ist eine Eigenschaft zur Anpassung des Abstands zwischen Wörtern
• shape-margin und shape-outside sind Eigenschaften, die festlegen, wie Text um Bilder oder Objekte herumfließt
• Wird von E-Mail-Clients noch nicht breit unterstützt

Neuigkeiten zum Caniemail-Update im März 2024 (29. März 2024)

• Eine Zusammenfassung der Updates, die im März 2024 der Caniemail-Website hinzugefügt wurden

Neuigkeiten zum Caniemail-Update im Februar 2024 (29. Februar 2024)

• Eine Zusammenfassung der Updates, die im Februar 2024 der Caniemail-Website hinzugefügt wurden

Stand der CSS-Eigenschaftsunterstützung in E-Mail-Clients

• Apple Mail (macOS): 267 von 284 unterstützt
• Apple Mail (iOS): 266 von 284 unterstützt
• Samsung Email (Android): 239 von 284 unterstützt
• SFR (Desktop Webmail): 226 von 257 unterstützt
• WEB.DE (iOS): 222 von 235 unterstützt

Einführung in die Caniemail-Website

• Eine Website, die von @HTeuMeuLeu und dem Team von Tilt Studio gestartet wurde und gepflegt wird
• Basiert auf dem ursprünglichen caniuse.com von @Fyrd und wurde von @Lensco gestaltet
• Basiert auf der ursprünglichen Idee und dem Namen von @M_J_Robbins und dem Team von Rebel
• Die Community der E-Mail-Entwickler auf GitHub unterstützt Beiträge zu den Daten
• Bei Problemen wird darum gebeten, Bugs auf GitHub zu melden

Meinung von GN⁺

• Eine sehr nützliche Website für E-Mail-Entwickler, auf der sich die Unterstützung von CSS-Eigenschaften in den einzelnen E-Mail-Clients auf einen Blick erfassen lässt. Beim Einsatz neuer CSS-Eigenschaften in E-Mails ist sie für Kompatibilitätsprüfungen unverzichtbar.
• Die CSS-Unterstützung von E-Mail-Clients ist im Vergleich zu Webbrowsern noch deutlich eingeschränkt. Vor allem animationsbezogene und layoutbezogene Eigenschaften werden kaum unterstützt, was die Grenzen des E-Mail-Designs mitbestimmt.
• Da regelmäßig über Updates informiert wird, dürfte die Website E-Mail-Entwicklern helfen, auf dem neuesten Stand zu bleiben. Allerdings ist der Update-Rhythmus so kurz, dass es auch anstrengend sein könnte, alles zu verfolgen.
• Ähnliche Websites sind etwa EmailOnAcid und Litmus; der Unterschied besteht darin, dass diese Vorschaubilder als Screenshots des Renderings in den jeweiligen Clients bereitstellen. In Kombination mit Caniemail könnte das einen Synergieeffekt bringen.

[GN⁺]

Meinungen auf Hacker News

• Hervorragende Ressource, und Outlook ist wirklich ein Graus und unterstützt viel zu wenig.
  Beim Erstellen von E-Mail-Templates für Benachrichtigungen in Unternehmens-Apps war es meist mühsam, aber nachdem wir auf MJML(https://mjml.io/) umgestiegen sind, lief es deutlich besser.
  Auf den verschiedenen getesteten Geräten wirkte das Ergebnis am kompatibelsten, und mit Litmus(https://litmus.com) haben wir das Rendering in unterschiedlichen Apps und auf verschiedenen Geräten geprüft. https://testi.at/ aus einem anderen Thread habe ich ebenfalls ausprobiert, und das passte auch gut.

  • MJML sieht interessant aus. Es wäre schön, wenn Organisationen einen geschäftlichen Grund hätten, sich um zugängliche und maschinenlesbare E-Mails zu kümmern.
    HTML-E-Mails stecken fest wie das Web zu IE6-Zeiten; für die wenigen E-Mail-Arbeiten, bei denen man mehr braucht als eine Liste von Bild-Tags, habe ich Foundation for Emails(https://get.foundation/emails.html) verwendet und bin dankbar, dass es existiert.
  • MJML ist in diesem Bereich mit Abstand das beste Tool, und ich nutze es häufig. Wenn man 2024 E-Mails baut, ist es eine wichtige Abkürzung, um die großen Schmerzen von HTML-E-Mails zu vermeiden oder zu verringern.
  • Für die Erstellung von E-Mails empfehle ich auch react-email(https://react.email). Es bietet genügend Komponenten und ist viel besser, als wie früher im E-Mail-Marketing alle fünf Zeilen Tags einzufügen, um eine Mail zusammenzubauen.
  • Outlook ist heute wohl so etwas wie der Internet Explorer der E-Mail.

• Zu dieser Site gibt es eine lustige Anekdote. Der Betreiber sagte einmal, in den Nutzungslogs fänden sich viele Spuren von Leuten, die den Zweck der Site missverstanden, Namen von Prominenten eingegeben und versucht hätten, ihnen E-Mails zu schicken.

  • Anfangs habe ich versucht herauszufinden, was das ist, konnte aber keine wirkliche Erklärung finden. Es heißt, es sei „so etwas wie caniuse für E-Mail-Inhalte“; wenn man aber nicht weiß, was caniuse ist, ist das schwer zu verstehen.
    Bevor man einen neuen Service veröffentlicht, wäre ein kurzer Erklärungsteil hilfreich, damit durchschnittliche Nutzer erkennen können, worum es geht.

• Je niedriger die Punktzahl, desto besser. Ich kenne einige Leute mit der Policy: „E-Mail erlaubt nur Plain Text, Anhänge ohne vorherige Absprache sind nicht erlaubt, und der Rest wird automatisch gelöscht.“

  • Eine kleine Erweiterung über Plain Text hinaus ist sinnvoll. Es geht nicht nur um Dekoration; für Dinge wie von rechts nach links geschriebene Sprachen, Listen und Links hilft ein wenig Markup, und HTML reicht dafür aus.
    Das Problem liegt darin, CSS übermäßig einzusetzen oder sogar JavaScript zu erlauben. Mir fällt kein Sicherheitsproblem bei E-Mails ein, das allein durch HTML ohne CSS oder JavaScript entstanden wäre.
  • Ich kenne mindestens zwei Personen, die E-Mails verschicken, deren HTML-Version leer ist oder nur „benutze keinen aufgeblähten Client“ sagt, während der eigentliche Inhalt im Plain-Text-Fallback steckt.
    Um sie in Thunderbird zu lesen, musste man, glaube ich, den Quelltext der E-Mail ansehen.

• Verwandte Links:
  Can I Email? - https://news.ycombinator.com/item?id=27112960 - Mai 2021, 273 Kommentare
  Can I Email: ‘Can I Use’ for email - https://news.ycombinator.com/item?id=20948826 - September 2019, 196 Kommentare
  'Can I Use' for Email - https://news.ycombinator.com/item?id=20934601 - September 2019, 1 Kommentar

• Die zwei beliebtesten Clients, Gmail und Outlook, liegen auf Platz 25 bzw. 41, also ganz am unteren Ende.

  • Wenn man sich ansieht, was Gmail nicht unterstützt, sind darunter Dinge wie display: none, Animationen und sonstiges CSS, das man kaum als unbedingt notwendig für E-Mails bezeichnen kann.
    Die Grundlagen sind vorhanden, daher muss ein hoher Rang nicht unbedingt ein gutes Ziel sein.
  • Das erinnert an den Internet Explorer, der zwar am beliebtesten war, aber wenig Features hatte.

• Ein voll ausgestattetes HTML-„Dokument“ ist eigentlich weniger ein Dokument als vielmehr eine Anwendung, daher ist es nachvollziehbar, dass Mail-Clients die Unterstützung einschränken.
  Wegen dieser Fragmentierung wünsche ich mir aber einen echten Standard. Wir brauchen ein offizielles Nicht-Anwendungs-HTML-Subset, das keine Remote-Ressourcen laden und keinen Code ausführen kann. Ein Dokumentformat mit eingebetteten Medien, Animationen, Styling usw. würde reichen.

  • Kann man es noch „Dokument“ nennen, wenn Animationen und nicht statische Videomedien enthalten sind?
  • Ehrlich gesagt gibt es keinen Grund, warum andere mir Code zum Ausführen oder Ressourcen zum Abrufen schicken sollten.
    Ich verstehe, dass die Ad-Tech-Branche meine E-Mail als Werbetafel nutzen möchte, aber sie soll sich bitte verziehen. Plain Text und Anhänge reichen aus.

• Zur Info: jsx-email hat eine eingebaute CLI-Prüfung für die Kompatibilität von E-Mail-Clients, die den caniemail-Datensatz verwendet: https://jsx.email/docs/core/cli#check

• Es wäre vermutlich nützlicher, nur die wenigen CSS-Eigenschaften aufzulisten, die alle E-Mail-Clients verstehen. Kein Witz, das meine ich ernst.
  Die Antwort von CanIEmail? ist meistens „nein“.

  • Wenn man auf https://www.caniemail.com/clients/ „check all“ auswählt, kann man getrennt sehen, welche Features von allen E-Mail-Clients unterstützt werden und bei welchen die Unterstützung uneinheitlich ist.
    Voll unterstützt werden offenbar ungefähr border-collapse, die Kurzschreibweise font, list-style-type, mehrere CSS-Einheiten (cm, em, ex, in, mm, pc, %, pt, px), vertical-align, einige HTML-Elemente und das Attribut valign sowie die Bildformate JPG/PNG.

• Zuerst dachte ich, es sei eine Scherzseite, die in großer Schrift nur „No.“ anzeigt.

  • Das ist normalerweise auch meine Standardantwort, wenn das Designteam um Updates an E-Mail-Templates bittet: „Geht nicht. Nur Basisformatierung. Wenn ihr etwas mutiger sein wollt, vielleicht Tabellen. Mehr nicht.“

• Dark-Mode-Unterstützung in E-Mails gehört zu den frustrierendsten Dingen, die ich als Frontend-Entwickler erlebt habe, der seit den IE6-Zeiten programmiert.
  Im Grunde kann man nur ein Light-Mode-Design umsetzen und Farben auswählen, die auch dann noch okay aussehen, wenn schlampige Dark-Mode-E-Mail-Clients sie automatisch invertieren.
  Gmail ist eines der schlimmsten Beispiele. Es gibt keinerlei Möglichkeit, im Dark Mode eigene Farben festzulegen.