At yesterday’s Inbox Love conference, we crossed the curtain between us email designers and high-profile email service providers, including Microsoft Outlook, Gmail, Lavabit and more. Not wanting to waste this rare opportunity to collaborate with the people that make or break our email campaigns, we discussed CSS support, the future of Google’s email clients and of course, #letsfixemail.
Bringing the spark to Microsoft’s otherwise serene campus in Mountain View, CA was the panel, “CSS Support in Email: The Problem We Should be Fixing First“. In front of an audience of over 150 product managers and decision makers, our “dream team” – Andrew King at Lyris, Justin Khoo at FreshInbox/CampaignWorkHub, Colin Nederkoorn at Customer.io and myself (Ros) as moderator – put email design on the agenda, with a lively discussion on email’s shortcomings and solutions.
— FreshInbox (@FreshInbox) October 30, 2014
After we asked for your help via our earlier post and #letsfixemail on Twitter, we received a variety of suggestions for our panel. Overall, the recurring theme was the uneven state of HTML email rendering across email clients today – and how that was holding us back as an industry.
— AHHHH!ctionRocket (@ActionRocket) October 29, 2014
First of all, the people who plan, design and build email clients are seldom email designers – and often have little to no understanding of the issues that poor CSS support can present to both senders and recipients. “What are media queries?” was heard from a to-remain-unnamed lead at an upcoming email service, indicative of the divide between those whose business is to display HTML email and the designers, coders and marketers who create it in the first place.
— Justine Jordan (@meladorri) October 29, 2014
This isn’t to suggest a lack of skill on the part of email service providers – and the intention of our panel was never to divide or alienate the email communities. Instead, we focused on what we share in common – and that’s a struggle with the preprocessors and rendering engines that determine what content should be displayed or dumped in the inbox.
Woah, preprocessor what?
Without wanting to stray too far into developer territory, almost all email clients preprocess HTML email in some way. The job of a preprocessor is to remove anything that could be dangerous, introduce privacy concerns, or cause an email to behave unexpectedly. For example, Gmail automatically removes scripts, while Outlook disables forms to prevent email recipients from unwittingly submitting sensitive data.
For the most part, this is a good thing for email recipients. However, having our code manipulated can also degrade the email experience by breaking layouts and forcing recipients to zoom in order to read text. It also can make testing a nightmare for email designers.
But that’s only the first hurdle. Once an email has been preprocessed, it’s ready for the rendering engine to take over and display whatever is left. And like the bad old days when Safari, Chrome, Opera, Internet Explorer etc just couldn’t agree on the box model, email clients almost never support CSS properties in a consistent manner.
The problem – as we discovered at Inbox Love – is that email client development teams do not collaborate. There is zero – and I mean zero – documentation on what standard, non-threatening CSS elements should be supported. So in the case of Outlook.com, you get choppy margin support and no media queries whatsoever.
Rendering engines are, I dare say, a more political affair. While WebKit (used by Apple OS X and iOS Mail) is the email designer’s choice for the near-web experience it provides, Microsoft has differing opinions… And valid reasons for using Word as its current rendering engine, even if it does cripple HTML email. For the email clients that aren’t affiliated with a project or ecosystem of products, the rendering engine is a subjective and usually home grown affair.
You may ask why all HTML email can’t display in iframes – and thankfully, we were taken to school on this point by the FastMail team. Quite simply, implementing a full-blown browser in an email client is a massive resource hog – so in order to save the CPU cycles and reduce email load times, pretty much all email clients implement scaled-back, bespoke rendering software.
And thus the mess we’re in today.
Sadly, the answer isn’t as simple as getting all email client product people in one room with foam batons and no way out. Somebody – let it be the W3C, or a developer with clout – has to come up with both a model for effective preprocessing and a modern “email acid test” as benchmark for rendering engines. Neither task is what you would call trivial – but they’re the big baby steps that will eventually lead us to consistent CSS support and I dare say, email standards.
Will Google finally go responsive with Inbox?
So, I’ve made you read this far to get to the exciting bits about Google’s brand-new Inbox email client. Aaron here did a great job of summarizing what it is, so I’ll skip the greens and get to the mains. As Shalini Agarwal, the Product Manager at Inbox (and formerly PM at Gmail) presented at her session, “About Google Inbox, from Google“, Inbox’s focus is to help users overcome the difficulties in managing both incoming email and to-do lists. The result is an inbox in which the important, actionable bits of say, bills and boarding passes are displayed as “Highlights”, and emails which require similar actions – like deleting – can be grouped into bundles and dealt with in one go.
The implications of this objective-focused system will be fodder for another blog post; what’s important for designers to know now is that Inbox does not support media queries. So you can’t optimize your email newsletters for either Inbox or Gmail on mobile devices.
— Justine Jordan (@meladorri) October 29, 2014
However, this may all change soon. When pressed by panelist and email blogger Justin Khoo, the Inbox team confirmed that while responsive techniques are not supported now, media query support is on the roadmap and is a priority to the app team. After years of downright begging, we’ve finally received confirmation that Google has heard us and plan to make it possible to adjust text for reading comfort, ensure images don’t extend beyond the viewport and ultimately, allow our messages to be read on any platform.
— Ros Hodgekiss (@yarrcat) October 29, 2014
And that’s a wrap for Inbox Love in 2014. You can download the slides from “CSS Support in Email: The Problem We Should be Fixing First” in PDF format via this link and view further resources here. Stay tuned to this blog as we’ll be featuring more on the state of CSS support in email, as well as further analysis on Inbox by Google.