Warum HTML-Mails in jedem Programm anders aussehen

« Blog · Von

Eine HTML-Mail wird gebaut, im Browser geprüft, verschickt — und kommt bei einem Teil der Empfänger als Trümmerhaufen an: Spalten übereinander statt nebeneinander, Schaltflächen ohne Rundung, Schriftarten ersetzt, Hintergrundbilder verschwunden. Der Grund ist ernüchternd: Es gibt keinen Standard dafür, wie ein Mailprogramm HTML darzustellen hat. Jedes tut es anders, und einige tun es sehr anders.

Der Hauptgrund heißt Word

Die einzelne größte Ursache ist eine Entscheidung von 2007. Outlook auf Windows stellte damals von der Anzeigekomponente des Internet Explorers auf die Textverarbeitungsmaschine von Word um.

Damit stellt die klassische Outlook-Fassung E-Mails nicht mit einer Browsermaschine dar, sondern mit dem, was ein Textverarbeitungsprogramm für Layout hält. Word kennt Tabellen und Absätze hervorragend. Modernes CSS kennt es nicht — nicht schlecht, sondern gar nicht.

Das erklärt fast alles, was in Outlook anders aussieht: keine abgerundeten Ecken, keine Hintergrundbilder über CSS, keine Media Queries, kein Flexbox, keine Webschriften, bei bewegten Bildern nur das erste Einzelbild.

Outlook(Windows) Gmail(Web) AppleMail Thunder-bird Inline-CSS am Element style-Block im Kopf Media Queries Flexbox und Grid Hintergrundbild per CSS Webschriften border-radius Bewegtes GIF voll eingeschränkt nicht unterstützt
Eine Spalte fällt aus der Reihe. Wer sie ignoriert, baut für drei Programme und gegen eines — und dieses eine steht in vielen Unternehmen auf jedem Schreibtisch.

Die übrigen Unterschiede

Gmail im Browser entfernt einen Teil dessen, was im Kopf der Nachricht steht, und kennt einige Eigenschaften nicht, weil sie das Seitenlayout stören würden — position und negative Abstände etwa. Webschriften über @font-face werden entfernt.

Apple Mail benutzt dieselbe Anzeigemaschine wie Safari und ist mit Abstand das großzügigste Programm. Wer nur dort prüft, hält seine Nachricht fälschlich für in Ordnung.

Thunderbird liegt nah an Firefox und ist ebenfalls großzügig, mit Einschränkungen bei Schriften aus dem Netz.

Der dunkle Modus, der zweite Bruch

Seit die meisten Programme eine dunkle Darstellung anbieten, gibt es eine zweite Quelle für Überraschungen — und sie ist unangenehmer als die erste, weil sie auch gut gebaute Nachrichten trifft.

Die Programme gehen unterschiedlich vor. Einige lassen die Nachricht unverändert. Einige tauschen nur Farben aus, die nicht ausdrücklich gesetzt wurden. Und einige kehren die Farben der gesamten Nachricht um, gesetzte eingeschlossen.

Das führt zu dem bekannten Bild: ein dunkles Logo auf einem Hintergrund, der eben noch weiß war und jetzt schwarz ist. Oder Text, der lesbar wäre, wenn nicht die Farbe umgekehrt worden wäre, die Hintergrundfarbe des umgebenden Kastens aber nicht.

Der verlässlichste Gegenzug ist unspektakulär: Bilder mit einem Rand versehen, der in beiden Modi funktioniert, oder als PNG mit durchsichtigem Hintergrund ausliefern und die Farbe darunter setzen. Und keine Textfarbe verwenden, die nur vor einem bestimmten Hintergrund lesbar ist.

Die Regeln, die daraus folgen

  1. Layout mit Tabellen. Nicht, weil es schön ist, sondern weil <table> das Einzige ist, was jede Anzeigemaschine gleich versteht — Word eingeschlossen.
  2. CSS ans Element, nicht in den Kopf. Ein style-Attribut überlebt überall. Ein style-Block überlebt nicht überall.
  3. Eine Spalte, höchstens 600 Pixel breit. Das ist die Breite, mit der der Vorschaubereich von Outlook zurechtkommt, und auf dem Telefon ohnehin die einzige sinnvolle Anordnung.
  4. Schaltflächen als Tabellenzelle mit Hintergrundfarbe, nicht als gestaltetes <a>. Ein Link ohne Rundung bleibt ein Link, eine Schaltfläche ohne Fläche ist unsichtbar.
  5. Alternativtexte an jedes Bild. Viele Programme laden Bilder erst nach Zustimmung — bis dahin ist der Alternativtext die ganze Nachricht.
  6. Keine Aussage nur im Bild. Wenn der Rabattbetrag ausschließlich im Banner steht, sehen ihn Empfänger mit abgeschalteten Bildern nie.
  7. Eine echte Textfassung mitschicken. Sie ist nicht nur für Textprogramme da; sie fließt auch in die Bewertung ein, ob eine Nachricht nach einer Aussendung aussieht.

Prüfen, nicht hoffen

Die Darstellung lässt sich nicht ableiten, nur ansehen. Der Weg dafür ist unspektakulär: Für jedes Programm, das im Empfängerkreis vorkommt, eine Adresse anlegen und die Nachricht dorthin schicken.

Genau dafür sind kurzlebige Adressen praktisch — eine je Programm, eine je Durchgang, ohne dafür Konten anzulegen. Über eine Schnittstelle lässt sich das auch automatisiert erledigen: Adresse erzeugen, Nachricht dorthin schicken, den empfangenen HTML-Teil abholen und mit dem vergleichen, was verschickt wurde. Was der Empfänger daraus macht, sieht man damit zwar nicht — was unterwegs entfernt wurde, sehr wohl.