Thoughts on Webmail CSS Support #Letsfixemail
I’ll be on a panel next week at Inbox Love lamenting the lack of CSS support for email. Naturally I’ve been thinking on what needs to be done to address this issue. For this post, I’ll focus on the Webmail clients – Gmail, Yahoo! Mail and Outlook.com.
The changes I’d like to see from the Webmail camp can be boiled down to three things: Visibility, Consistency and Reliability. I would like us to get into the place where even though there may still be incomplete CSS support, email coders are finally able to know what they need to do for emails to render properly in Webmail – and not having to test, troubleshoot and dig around for answers on each platform.
Here is my wish list:
1) Eliminate client specific quirks
Some of the quirks present in email clients make no sense and only confound email coders trying to create decent looking messages.
- Support embedded styles in Gmail mobile apps and stop stripping id’s and classes from elements.
- Support the display:block style in elements (without the need to add !important).
- Stop converting the height style to min-height.
- Stop setting line-height to 142%
- Support background-image style
- Fix that damn CSS processor that keeps activating our mobile media queries
(Update: Yahoo! fixed this in early 2015. You get a gold star Yahoo! Mail!)
2) Common CSS support
Complete CSS support on Webmail is problematic because of the need to “sandbox” the content within a window within the Webmail app. So I understand if absolute positioning and certain more exotic capabilities like CSS animation might be curtailed.
However would it be too much to strive for consistent support across the three different clients? For reference here are CSS support lists managed by Campaign Monitor and MailChimp.
If a style is supported by two out of the three Webmail platforms, the platform that doesn’t support the style should make a commitment to support it.
3) Universal override scheme
Its not surprising that the webmail clients often add their own flavor when rendering emails – such as link styles, line-heights and font sizes.
However, sometimes we would prefer the emails to render a certain way across all clients, and doing so require the knowledge of “magic” classes like ExternalClass, ReadMsg and yshortcuts.
It would be nice if there was a universal method to override these changes, perhaps using a common class name like “.clientsstyle”. That way each webmail client can still add their flavor to their app, but when needed designers have a simple and straightforward way to setting them back.
4) Documentation, documentation, documentation!
Here’s the rub. Google, Yahoo! and Microsoft all have pretty sizable developer programs for their email platforms. Gmail has Inbox Actions, Gadgets and the Gmail API. Yahoo! Mail has the Yahoo Mail Web Service, and Outlook has a plethora of Integration options for Office365, Outlook.com and Exchange.
All of these programs come with very good documentation.
However, none of these platforms have any documentation on how email messages are processed and rendered. As email coders we have to resort to 3rd party resources to navigate the various email client nuances.
Whats with the double-standards? Are email coders seen as less worthy of support than app developers?
Perhaps they prefer to keep the bad email senders in the dark? Well that is just Security through obscurity. The bad guys can figure this all out by themselves the only outcome is tons of wasted hours troubleshooting email whenever a webmail platform makes some random change in the way emails are rendered.
Microsoft, Google and Yahoo! we would REALLY be grateful if you would start to provide some documentation on your email processing and rendering process – and the first one to do so would get a collective cheer of gratitude from the email community.
So thats my wish list. All I’m asking for is a bit more visibility, consistency and reliability around how Webmail handles email especially when it comes to CSS. Feel free to chime in in the comments if you feel the same or if you have other thoughts and ideas! #Letsfixemail !
The fourth point on your list is SO important, and it was only when reading it did it strike me that, nope, as email marketers so much of what we know about email rendering has been about trial and error, and then sharing that knowledge.