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.

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.

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.

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.

Mobile and desktop views of Inbox by Google

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.

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.

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.

  • Julia Myers

    If you do ever need a collection of foam batons, just holler. I also adore the term “bespoke rendering software” but it won’t parse with my boss. Thanks ever so much for the synopsis and insights.

  • Mark

    Great stuff Ros.

    It’s great to finally start making contact with the other side. I look forward to seeing if/how/when things start to change in inbox and beyond.

    Cheers,
    Mark

  • Dan

    I hope they don’t kill it before it really takes off :)

  • Ros Hodgekiss

    Hah, thanks Julia, Mark and Dan! Happy to share the highlights from what was an awesome day. We’ll be sure to keep you posted as we hear more from both our new email client friends and hopefully, the Inbox by Google team!

  • Jaina

    It’s kind of an exciting time in email when there’s finally a sense of communication between those who develop the email platforms that we, as email geeks, spend so long try to create content for.

    I do wonder if the potential media-query support for Inbox will extend to Gmail. I wonder this because, as far as I can tell, Inbox shares the same HTML rendering as Gmail. And compound this with fact that with Android 5.0, they’re doing away with the standalone email app, in favour of Gmail, which will support Yahoo and Outlook.com email. There is going to have to be some major developments from Google if they’re to able to do everything the built-in email app did.

    Regardless, I think email is moving pretty quick nowadays!

  • Terri Swiatek

    This is exciting to hear on a challenge most would say is a lost cause with so many different stake holders. Press on!

  • Andrew King

    Litmus have some great articles on how preprocessors and rendering engines change our emails here:

    https://litmus.com/help/email-clients/rendering-engines/?utm_source=litmusblog&utm_medium=blog&utm_content=helparticle&utm_campaign=rendering

  • Ros Hodgekiss

    This is awesome, Andrew – thank you for being a great friend to the email community and bringing so much to the panel :)

  • brian

    Thanks a lot for this news !
    i can’t wait for this to happen, this should have been done years ago..
    This is weird for a company like google to still not use media queries, even Microsoft did with their mobile phones…the world’s gone crazy or what?
    They should know android platform will be the most use in the future…

  • AJ

    I haven’t been reading up on Inbox, but it seems to me it will affect open rates negatively with Highlights.

    As for the old Gmail, are there any plans to finally render CSS defined in the head tag? This way we don’t have to keep using inline styles.

  • Ros Hodgekiss

    Hi there AJ, I think time will tell on this one. Sadly, there hasn’t been anything said on the future of Gmail – while we assume it will continue to remain under development, the whims of Google are largely unknown to us :) Stay tuned to this blog and we’ll let you know if we hear anything more!

Want to improve your email marketing? Subscribe to get tips on improving your email marketing delivered to your inbox.
X

Join 200,000 companies around the world that use Campaign Monitor to run email marketing campaigns that deliver results for their business.

Get started for free