Das Elend der HTML-Mail

• 10.04.06, 19:25 | Vermischtes, Werkstatt

Ja, ja, ja: HTML-Mails sind böse. Jeder, der sich mit der Materie auch nur ein wenig näher beschäftigt, weiß das. Sie führen das Prinzip E-Mail ad absurdum, treiben die Belastung des Netzes ohne Not nach oben, entsprechen keinerlei Standard und sorgen auch sonst für mehr als genug Probleme. Also alles andere als die reine Lehre.

Der Punkt ist, dass sich die Mehrzahl der Menschen für die reine Lehre nicht im entferntesten interessiert und es gibt keinen Grund, ihnen das vorzuwerfen. Zahllose Unternehmen betrachten gestaltete Newsletter als probates Marketing-Instrument und die oft in die Tausende gehende Zahl der Abonnenten, die den Empfang ausdrücklich wünschen, gibt ihnen fraglos recht. Zumal dann, wenn eine reine Textalternative angeboten wird, und sich der Prozentsatz derer, die diese Fassung vorziehen, (in aller Regel) unter 5 Prozent bewegt (auch wenn sich die Quote vorwiegend aus Unwissenheit speisen wird). Also: was tun, wenn ein Kunde ein solches Newsletter-Tool möchte?

Wer schon mit uns zusammengearbeitet hat, weiß, dass wir unsere Auffassungen zwar leidenschaftlich, mitunter auch undiplomatisch darlegen – letzten Endes sind wir aber Pragmatiker und keine fundamentalistischen Prediger. Also haben wir schon – obwohl wir weiß Gott keine HTML-Newsletter mögen – eine ganze Reihe entsprechender Tools produziert. Nicht ohne dem Kunden vorher die Nachteile und Konsequenzen deutlich aufzuzeigen, auch auf die Gefahr hin, einen Auftrag zu verlieren – von dem wir immerhin leben. Unserer Beratungsverantwortung sind wir damit wohl nachgekommen, und wenn der Kunde sich im Wissen um die Nachteile dennoch für den HTML-Newsletter entscheidet, werden wir uns dem Wunsch sicher nicht verweigern.

Nachdem wir die grundsätzlichen Fragen damit hoffentlich geklärt haben, wenden wir uns lieber dem Gegenstand als solchen zu. Idealerweise gibt es ein Backend, mit dem der Newsletter zusammengestellt werden kann. Lassen wir Umfang und Features mal beiseite (Personalisierung, individuelle Konfigurationsoptionen, Bilder/keine Bilder etc.), das ist nicht das Problem. Letzten Endes wird der Inhalt zu einer gewöhnlichen HTML-Seite gepackt, parallel dazu wird die Textfassung als reine Textdatei erzeugt und beides wird – abhängig von den jeweiligen Präferenzen, in einer der beiden Formen verschickt.

Die Textfassung ist weitgehend unproblematisch, was niemand verwundern wird, ist sie doch nichts anderes als eine handelsübliche E-Mail, die der reinen Lehre folgt. Bei der HTML-Fassung empfiehlt sich eine sog. »multiple-part message«, die sowohl die HTML- als auch die Textversion enthält. Das versendete Volumen erhöht sich damit zwar noch weiter, aber viele Mail-Clients bieten entweder eine Umschaltoption oder zeigen die Textfassung automatisch an, falls sie mit der HTML-Version Schwierigkeiten haben. Auch diese Fassung ist weder schwer zu erzeugen noch zu verschicken und theoretisch könnte der Job erledigt sein, wenn sowohl das Zusammenstellen als auch das Verschicken fehlerfrei läuft.

Praktisch fangen die Probleme jetzt erst an. Die haarkleine Auflistung aller Schwierigkeiten wäre eine ziemlich langatmige Liste, beschränken wir uns also auf eine Zusammenfassung der wichtigsten:

Halbwegs aktuelle Mail-Clients

• Einzige gute Nachricht: Clients wie Outlook, Entourage, Thunderbird, Apple Mail etc. zeigen ziemlich ordentliche Ergebnisse.
• Für die Layouts empfehlen sich altbackene Tabellenkonstruktionen, alles andere ist ausgesprochen unzuverlässig.
• Vergessen Sie jeden Versuch, Lotus Notes HTML und/oder CSS beizubringen. Beides wird nur sehr partiell interpretiert, ein Layout, das den Namen ansatzweise verdient, ist mit dieser Beschränkung des Vokabulars nicht zu schaffen.

Webmailer

• Zumindest für web.de, gmx.net und hotmail.de gilt: alle panschen im Quellcode herum, und zwar nicht zu wenig.
• UTF-8-Kodierung führt bei fast allen Webmailern zu Zeichensalat, weil sie den Text unterwegs auf LATIN-1 umkodieren, also nehmen Sie lieber gleich LATIN-1.
• Vergessen Sie CSS als eigenständigen Block im head-Bereich, die meisten löschen ihn ersatzlos.
• Ein CSS-Block kann (auskommentiert!) im body-Bereich stehen, dann bleibt er zumindest teilweise erhalten. Der sicherste Weg ist, den CSS-Block so knapp wie möglich zu halten und den Rest per Inline-CSS zur regeln.
• hotmail.de geht allerdings soweit, selbst Inline-CSS zu überschreiben, beispielsweise wird alles rausgeschmissen, was margin heißt, während padding akzeptiert wird. Auch Linkfarben sind allenfalls zu bestimmen, indem jeder einzelne Link per CSS eigens eine Farbanweisung erhält, wenn nicht, erscheinen alle im standardisierten »Königsblau«. Unterm Strich ist hotmail.de darstellungstechnisch der mit Abstand übelste unter allen gestesteten Webmailern.
• CSS-Vererbungsregeln sind de facto außer Kraft gesetzt, will meinen, es ist keinerlei Verlass auf sie.
• Einige Webmailer überschreiben das body-Tag im HTML, was dazu führt, dass weder CSS-Eigenschaften die für body gelten funktionieren, noch alles, was als »Erben« daran hängt.

Was hier knapp zusammengefasst ist, bedeutet in Wahrheit Trial & Error ohne Ende – je nach Komplexität des Layouts schafft man es mühelos, dem Wahnsinn nahe zu kommen. Bis das HTML/CSS an allen Stellen wenigstens so weit passt, dass man nicht mehr von Katastrophen sprechen muss, mutiert es zu einer kruden und umständlichen Mischung aus hoffnungslos veraltetem HTML und Billig-CSS, das sehr umständlich geschrieben werden muss. Im Fall von Lotus Notes ist selbst damit noch Hopfen und Malz verloren.

Fazit also: Falls Sie auf die Idee kommen, einen HTML-Newsletter verschicken zu wollen, überlegen Sie sich das lieber noch mal in aller Ruhe. Und zwar durchaus im pragmatischen Sinne, von der reinen Lehre mal ganz abgesehen.