GMail & Media Queries – Email Developers Heaven is Still far Away

GMail gets responsive. The big news spread quickly during the past weeks as everybody got excited about a news that actually should not even be worth a news because in my opinion it should be implemented already years ago. Especially since Google is considering the responsiveness of websites for it’s holy grail page rank algorithm… In German we call this kind of behavior «Wasser predigen und Wein trinken» («Preaching water but drinking wine»). Anyway, I was playing with the new GMail pre-processor a bit. Here are my first learnings:

1. GMail combines all style blocks into one

Does not matter how many stile blocks you are using, GMail combines them all into one which is dynamically added to the DOM at the very end of the <head> section.

2. Selectores are not supported anymore

It seems that GMail does not like css selectors anymore. Hacks such as using the «lang» attribute documented by freshinbox here are not working anymore. It does not matter how the selectors which selector we are using, nor how we write it. GMail shows no mercy: they simply get stripped. None of the following is supported since the last update:
 [title~="gmail-selector"] {display: block !important;}
 div[lang~="gmail-selector"] {display: block !important;}
 *[width~="gmail-selector"] {display: block !important;}
 * [height="gmail-selector"] {display: block !important;}
 * [alt~=gmail-selector] {display: block !important;}
 * [href=gmail-selector] {display: block !important;}

 * div[foo] {display:block !important;}
 * div[foo=bar1] {display:block !important;}
 * div[foo~=bar2] {display:block !important;}
 * div[foo^="bar3"] {display:block !important;}
 * div[foo*="bar4"] {display:block !important;}
 * div[foo$="bar5"] {display:block !important;}
Check my test code out here: https://codepen.io/cygro/pen/gwvqGK?editors=1000#

3. Media queries with multiple rules (comma delimited) are supported

At least something ;-)

4. GMail does not like numbers in class names

Some developers tend to use numbers in class names. Even at the beginning of a class name. This is not among best practices and GMail enforces you now to avoid it: If a class name starting with a number (such as .600-no-max-width) ANYWHERE in your <style> block, GMail will simply strip the entire block. All your other nice classes and media queries are gone.

5. No support for neighbor / sibling operator

The core coding pattern used for interactive email is not supported by gmail. The required combination of the :checked pseudo class and neighbor / sibling operator is stripped out by gmail.

6. Full message view without css

All style definitions in the head are stripped in the full message view. If your message is beyond 102kB in total size (source size), it will be clipped and the following note will be added: «[Message clipped] View entire message» However, in the full message view (that pops up when you click on the link «View entire message», all <style> blocks are still stripped from the <head> section. To be continued…

Responsive ist nicht gleich responsive: Optimierung von E-Mails für Mobilgeräte

Über 50% der Öffnungen von E-Mails erfolgen heute auf Mobilgeräten. Einen guten Grund, E-Mails nicht für diesen Gerätetyp zu optimieren, gibt es nicht mehr. Diese Erkenntnis hat sich in den vergangenen Jahren glücklicherweise fast überall durchgesetzt. Aber: Responsive Design für E-Mails ist nicht mit responsive Design für Webseiten zu vergleichen. Als «Responsive Design» wird der Ansatz bezeichnet, eine Webseite – oder in unserem Fall eine E-Mail – so aufzubauen, dass sich die Darstellung automatisch der Bildschirmgrösse des empfangenden Gerätes anpasst. So werden beispielsweise die gleichen Elemente auf einem Desktop Computer nebeneinander und auf dem Smartphone untereinander angeordnet. Responsive DesignBei Webseiten lässt sich dank modernen Web-Browsern und einheitlichen Standards (HTML 5 / CSS 3) ein hohes Mass an Flexibilität in der Darstellung erreichen. Von Desktop-Bildschirmen mit Auflösungen von 2560×1440 Pixeln bis zu Smartphones mit 320×40 Pixeln können die Elemente möglichst optimal angeordnet und skaliert werden.

Limitierte Möglichkeiten auf Desktop E-Mail Clients

Von E-Mail Clients werden die gängigen Web-Standards leider nur sehr beschränkt unterstützt und der verfügbare Platz für die Darstellung der E-Mails lässt sich oft nicht ermitteln. Zudem kann keine Programmlogik (JavaScript) in eine E-Mail eingebaut werden. Als Best Practice hat sich eine Breite des E-Mail Inhaltes von circa 600 Pixeln durchgesetzt. Diese Breite wird auf den meisten Webmail-Clients (wie GMail, Bluewin oder GMX) sowie in der Vorschau von Desktop-Programmen wie Outlook meist vollständig angezeigt und kann bei Standardeinstellungen auf eine A4 Seite ausgedruckt werden.

«Liquid» auf Mobilgeräten

Responsive-Design iPhone-AndroidBei Smartphones ist in den vergangenen Jahren eine unüberschaubare Zahl an Bildschirm-Abmessungen entstanden. Die Breiten reichen dabei von 240 bis 480 Pixeln, was einer Bandbreite von 100% entspricht. Um mit diesen grossen Unterschieden umgehen zu können, setzt man heute vorwiegend auf die sogenannte «Liquid»-Variante des Responsive Designs, bei welcher die Elemente nicht anhand vordefinierter Schwellenwerte (sog. Break-Points) schrittweise skalieren, sondern sich «flüssig» der Bildschirmbreite anpassen. Der Nachteil dieser Variante ist, dass Bilder vom Endgerät skaliert werden. Das hat eine etwas schlechtere Qualität zur Folge, als wenn die Bilder über eine leistungsfähige Software wie z.B. Photoshop skaliert und in allen benötigten Grössen anhand der Schwellenwerte bereitgestellt werden. Ebenso ist eine Absatzkontrolle in Fliesstexten dadurch nicht möglich. Diese Nachteile werden jedoch durch die bessere Ausnutzung des verfügbaren Platzes auf dem Bildschirm und somit weniger Scrolling, sowie dem geringeren Aufwand bei der Erstellung der Mailings (weniger Aufwand bei der Bildproduktion) mehr als aufgewogen.

Neue Einschränkungen auf Google Plattformen

Für die Umsetzung der Responsiveness haben sich so genannte «CSS Media Queries» durchgesetzt. Diese werden von Apple-Geräten (iPhone/iPad) in der nativen Mail-App gut unterstützt. Auf der Android Plattform sowie verschiedenen Apps wie GMail, GMX oder auch Bluewin ist deren Unterstützung jedoch sehr uneinheitlich. Während die bei Android standardmässig installierte Mail-App bis Version 5 Media Queries noch unterstützt hat, werden diese von der neusten Version auf Android 6 wie auch von der GMail App, Inbox by GMail, Bluewin und der GMX-App komplett ignoriert. Löbliche Ausnahme ist hier für einmal Microsoft. Die Outlook Mobile App für Android und iOS unterstützt Media Queries einwandfrei. Wie soll man damit umgehen? Die skalierte Desktop-Ansicht ist auf Smartphones in der Regel unbrauchbar. Der «Mobile First» Ansatz, bei welchem E-Mails primär auf Mobilgeräte optimiert werden, führt auf klassischen Desktop-Clients, wie dem nach wie vor sehr weit verbreiteten Outlook, zu unschönen Darstellungsfehlern oder – im besten Fall – zu übergross angezeigten Bildern auf grossen Bildschirmen.

Der goldene Mittelweg: Hybrid-Coding

Mitte des letzten Jahres tauchten erste Ansätze des sogenannten «Hybrid-Codings» auf. Dabei wird der HTML Code so aufgebaut, dass auf Mobilgeräten und Apps ohne Unterstützung von Media Queries die Elemente wenigstens untereinander geschoben werden und somit der Inhalt der E-Mail auch ohne manuelles Skalieren lesbar ist. Hybrid DesignAuf Webmail- und Desktop-Clients werden die Elemente wie gewohnt nebeneinander angezeigt und auf mobilen Geräten mit Unterstützung von Media Queries greift die Liquid-Variante. Letztere beinhaltet sämtliche Optimierungen für den mobilen Medienkonsum wie alternative, optimierte Bilder, grössere Schriftarten, auf Touch-Bedienung optimierte Schaltflächen sowie mehr Abstand zwischen den klickbaren Elementen. Somit wird auf jedem Gerätetyp die bestmöglich optimierte Variante angezeigt. Und der Nachteil? Der Hybride Code wird noch einmal komplexer. Es müssen im Grunde drei unterschiedliche Ansätze der HTML-Entwicklung mit stark abweichenden Anforderungen in einem Quellcode zusammengeführt werden. Denn der Quellcode lässt sich, ist die E-Mail einmal versandt, nicht mehr verändern. Ein komplexer Code erhöht die Anforderung an den Entwickler, an das Testen und an die Wartung. Selbst hoch qualifizierte Web-Entwickler beissen sich an den Anforderungen von einem E-Mail Code die Zähne aus. Viele Designs lassen sich nur mit aufwändigen Tricks (sog. «Tweacks») umsetzen. Zum Testen müssen spezielle Plattformen sowie eine Auswahl an physischen Endgeräten eingesetzt werden. Hybrid-Design iPhone-AndroidWird eine Software wie das auf Campaign Monitor verwendet, kann in der Regel auf eine umfangreiche Bibliothek von Templates (Vorlagen) zurückgegriffen werden, welche nach neusten Coding-Standards entwickelt oder auf diese aktualisiert wurden. Werden jedoch Enterprise Systeme eingesetzt oder erlauben CI/CD Guidelines und Branding keinen Einsatz von Standard Templates, führt oft kein Weg an der Umsetzung eines Individual-Templates durch eine spezialisierte Agentur – mit entsprechenden Kosten – vorbei. Dafür ist aber auch garantiert, dass die Darstellung auf allen Clients soweit wie technisch möglich, optimiert und getestet wurde.