HTML Newsletter und W3C Validität


15.11.2016
Newsletter

Wann kommt es zu W3C Fehlern?

Als wäre das Leben der Designer und Entwickler von Newslettern nicht schon schwer genug, plagen die W3C Validatoren auch die letzten Stirnfalten in ihre Köpfe. Doch wobei handelt es sich bei der W3C Markup Valiadation? Hierbei geht es um eine Prüfung, bei der der eingegebene HTML-Code der Website oder des Newsletter auf Fehler und Form überprüft wird. Dies geschieht anhand von Doctypes, die meist zu Beginn einer HTML-Datei definiert sind.

Bei einem HTML5 Dokument steht in etwa so:

<!DOCTYPE html>

Dies kann bei älteren HTML-Versionen aber auch schon etwas komplizierter aussehen:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
An sich eine gute Sache, kann man doch hier erkennen, ob zum Beispiel HTML-Tags nicht geschlossen wurden. Dies würde zu Darstellungsfehlern führen und ist somit sicherlich nicht gewünscht. Es gibt jedoch auch zahlreiche Beispiele, bei denen der W3C Validator Alarm schlägt, die Website davon jedoch nicht negativ betroffen ist, ja sogar profitiert. Dabei handelt es sich um sogenannte Vendor-Präfixe. Diese sehen zum Beispiel so aus:
-webkit-border-radius: 12px;
-moz-border-radius: 12px;
border-radius: 12px;

Statt also einmal zu definieren, dass ein Element runde Ecken haben soll, muss es bei einigen CSS Eigenschaften für jeden Browser seperat angegeben werden. Dies wird aber vom W3C Validator mit einer Fehlermeldung abgestraft.

Was bedeutet das für meine Newsletter Templates?

Wer sich schon genauer mit Email Newslettern auseinandergesetzt, weiß auch, dass die Arbeit daran schon mal ziemlich frustrierend sein kann. Durch sehr unterschiedliche Darstellungen in den einzelnen Email-Clients, kommt man oft nicht drumherum, sogenannte Workarounds – improvisierte Notlösungen – einzusetzen. Wichtig sind die DOCTYPE-Validations für Newsletter insofern, als das sie auch hier rechtzeitig vor nicht geschlossenen Tags warnen. Denn ein moderner Browser wie Firefox oder Chrome kann schon mal hier und das einen Fehler verzeihen. Mailclients hingegen sind da nicht so kulant. Insofern ist der Markup Validator ein wichtiges Tool. Jedoch sind nicht  alle Fehlermeldungen auch wirklich relevant für die Darstellung und nicht alle Workarounds werden als korrektes Markup behandelt. So führt zum Beispiel dieser IE-Hack regelmäßig zu Validitätsproblemen:

<!--[if mso]>
...Outlook verwendet den Code...
<![if !mso]>
...Outlook verwendet diesen Code nicht...
<![endif]>

Darstellungsfehler sind mir mit diesem Hack noch nicht untergekommen, eine Fehlermeldung wirft es dennoch. Es lässt sich also festhalten, dass W3C Validatoren ein gutes Mittel sind, um Fehler schnell zu erkennen. Jedoch lässt sich nur mit dem nötigen Wissen feststellen, ob diese Fehler oder Warnungen sich in der Praxis negativ auf den Newsletter auswirken.

Welchen Doctype also für Newsletter verwenden?

Bleibt also noch die Frage, für welchen Doctype – und somit für welche Prüfung – man sich entscheidet. In diesem englischsprachigen Artikel etwa, testet Campaign Monitor zum Beispiel drei verschiedene Doctypes im Newslettereinsatz. Die Empfehlung lautet dabei, folgenden Doctype zu verwenden:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional //EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Jedoch fehlt in diesem Test meiner Meinung nach die loose.dtd-Variante, die in meiner Praxiserfahrung weitaus weniger „unnötige“ Fehler wirft und somit für einen Newslettereinsatz weitaus besser geeignet ist:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

Die Loose-Variante ist wesentlich gnädiger mit dem Code und erlaubt auch den Einsatz von veralteten Tags wie etwa <font>. Genau diese werden aber für einige Workarounds benötigt, weswegen hier eine Fehlermeldung lediglich Eulen nach Athen tragen würde. Auch die Newsletterprofis von Litmus empiehlt in diesem Kontext die zwei oben genannten Doctype in diesem sehr lesenswerten Artikel. Wer jetzt tatsächlich sogar neugierig geworden ist, wo die Unterschiede zwischen Loose.dtd und Strict.dtd liegen, dem sei dieser Artikel abschließend empfohlen.