Gmail just announced a drastic improvement in HTML and CSS support.

November 2016 update - support for responsive email is now rolled out for all Gmail users and apps, except non-Gmail addresses when viewed in Gmail iOS and Android apps.

The key benefit: we can finally provide an optimal mobile experience for nearly all of the mobile audience — a cursory look at the email client usage stats show that 16% of emails are opened in Gmail, and a further 10% in Google's various Android apps.

Some of the code aspects of email design just got a whole lot easier, allowing designers to focus on creating great email campaigns.

So what's supported?

The good news is that quite a lot is supported. From a design standpoint, there are two main benefits:

We can use media queries, bringing support for responsive design up to iPhone mail app standards and making responsive design the de-facto standard for (almost) all mobile users.
Support for the <style> tag means we can use classes to apply style to content, greatly reducing the need to inline code. That means a huge decrease in code size, and less time spent by email devs.

What's not included?

Notable by their absence on the list of supported style attributes are support for web fonts (including Google fonts), animations and pseudo classes like :hover and :checked. These have implications for interactive email, but I'm optimistic about there will be increased support in the future.

This changes everything

Email has been coded using tables and inline styles (aka coding like it's 1999) largely due to two email clients — Gmail needed inline styles and Outlook 07|16 don't like div based layout. Gmail allowing support for classes and ids means there is much less need to inline style any more. The versions of Outlook that need table based layout (i.e. the versions that use Word for rendering) are becoming less relevant — Outlook users are shifting to web based Outlook or other platforms, and there is already a movement to improve standards in Outlook.

That means we can finally bring email code up to 2016 HTML standards.

What about the hybrid technique?

The primary need for the hybrid technique (aka fluid/spongy/fluid-spongy) is to increase support in the Gmail app. And once Gmail support is increased, you can get away without needing it. But I'd still recommend it, for a few reasons:

1) We don't know yet if every iteration of the Gmail app will get increased support (and there are many — iPhone, Gmail, Business versions, Education versions, non Gmail accounts viewed in Gmail apps)

2) Starting off your layout with a fluid basis improves the mobile experience in the long tail of less used mobile email apps (all the way back to old school Blackberries). Plus there are inherent accessibility benefits from using a more fluid layout.

3) It's really not that difficult to use the basics of the Hybrid technique, so it's an easy win.

In my opinion, a hybrid base with responsive techniques layered on top, is the best approach for email development.

What does this mean for email designers?

Gmail just went from the worst to the best in terms of communication with email developers. They published documentation stating exactly what they do (and don't) support. Recently we've also seen a great dialogue with the folks at Outlook around similar issues, and in the past Yahoo! Mail have also interacted with us. I hope other email clients follow these examples.

The much improved support for CSS also means much less reliance on email hacks. That's a great thing, because hacky code (like the dir=rtl technique for example) can often cause secondary rendering issues elsewhere.

But most importantly, the huge opportunity here is time saving. Email designers and developers can now focus on the things that are important — creating a great message and experience for users, and creating a great email process to do that. In an industry where we often spend 8 hours a day trying to achieve the basics, this is a huge step forward.