Google has started rolling out their recently announced updates to their range of email clients. If you missed the big news, Google will now be supporting embedded stylesheets, including media queries, across all their clients, including Gmail on Android, iOS and webmail, Inbox on Android, iOS and webmail, and Google Apps webmail (now renamed G Suite).

Since then, we and email developers around the globe have been heads down in our inboxes, alternating between pinching ourselves and checking out how Gmail’s newfound CSS support works in practice. Today we wanted to share what we’ve found out so far.

Although Google announced the changes would be live by the end of September, deploying them to all accounts and apps has understandably taken some time. So far we’ve had the chance to test the updates in all clients except Gmail on Android and iOS, so we’ll go back and check once those update for us too.

Note that these updates are happening entirely on the server side, so no app updates are needed for them to take effect on your phone.

So, first things first: How do you access the new capabilities?

<style> in <head>

To include a stylesheet that will be accepted by Google’s email clients, it needs to be added as an embedded stylesheet (a <style> element) in the <head> of the HTML document.

Style element Gmail webmail Inbox webmail G Suite webmail Inbox Android Inbox iOS Gmail Android Gmail iOS
<style> in <head> Yes Yes Yes Yes Yes Yes To be tested
<style> in <body> No No No No No No To be tested
Link element Gmail webmail Inbox webmail G Suite webmail Inbox Android Inbox iOS Gmail Android Gmail iOS
<link> in <head> No No No No No No To be tested
<link> in <body> No No No No No No To be tested

The old practice of placing <style> in <body>, which was used to sneak stylesheets into the webmail clients of yesteryear, will not work in any of Google’s clients.

All of their clients also ignore external stylesheets added with <link> elements, which means they don’t leave a way for you to go back and change your styles after the email was sent.

Class and ID support added, attribute selector and :checked support removed

Next, we looked at CSS selector support. Before the update, Gmail webmail had limited support for embedded stylesheets. Their other email clients had no stylesheet support, allowing only inline styles.

Gmail’s otherwise fantastic reference of CSS support doesn’t cover what selectors they support, but here are our test results.

Selectors Gmail webmail Inbox webmail G Suite webmail Inbox Android Inbox iOS Gmail Android Gmail iOS
* Yes Yes Yes Yes Yes Yes To be tested
E Yes Yes Yes Yes Yes Yes To be tested
.classname Yes Yes Yes Yes Yes Yes To be tested
#id Yes Yes Yes Yes Yes Yes To be tested
Attribute selectors No No No No No No To be tested
Pseudo-classes Only :hover No Only :hover No No Only :hover To be tested
Pseudo-elements No No No No No No To be tested
E F Yes Yes Yes Yes Yes Yes To be tested
E > F Yes Yes Yes Yes Yes Yes To be tested
E + F Yes Yes Yes Yes Yes Yes To be tested
E ~ F Yes Yes Yes Yes Yes Yes To be tested
.chained.class Yes Yes Yes Yes Yes Yes To be tested

The big improvement here is the support for class selectors, and for some use cases, id selectors.

Attribute selectors, previously used for Gmail webmail as a workaround for the lack of class selector support, are no longer supported in any of the clients we tested. So if you have emails that relied on this hack for Gmail specific styles, now is the time to update those rules to class selectors instead.

Or if you have emails still using attribute selectors to hide mobile styles from Yahoo! Mail, you will want to change those too. Yahoo! Mail has since improved their rendering so the hack is no longer needed, but now the attribute selectors will hide the styles from Google’s clients instead, negating the benefit of the added media query support. Thanks to Elliot Ross from Taxi for Email for pointing this out.

Also gone is the support for :checked selectors, used in a variety of interactive email techniques.

The only pseudo-class selector supported in Gmail and G Suite webmail is :hover. In Inbox, :hover isn’t supported either.

Pseudo-elements such as ::before and ::first-line all get stripped out of your CSS.

Other than those limitations, all variations we’ve tested involving descendants, siblings, and chained selectors have worked beautifully across all clients.

Some minor CSS property issues

We’ve not run a comprehensive test of all values of each CSS property at this stage, but we’ve checked in the three webmail clients whether any properties get stripped out.

Testing the 142 properties listed in Gmail’s CSS support reference as properties that should be supported, we found the list to be mostly accurate. However, 14 of the properties were stripped of our test emails despite being the reference claiming support:

  • break-after
  • break-before
  • break-inside
  • column-count
  • column-fill
  • column-gap
  • column-rule
  • column-rule-color
  • column-rule-style
  • column-rule-width
  • column-span
  • column-width
  • columns
  • text-combine-upwrite

The properties starting with break or column all have to do with CSS columns, and text-combine-upwrite is a typographic property used in some international languages. Neither of these are widely adopted on the web yet, and support in other email clients is very low.

A more problematic issue is that Inbox replaces all instances of height with min-height properties with the same value. This has been an issue across all of Google’s email clients for years, making it difficult to maintain the aspect ratio of fluid images, among other things. After the rendering refresh, this problem is fixed in the Gmail and G Suite webmail clients but still remains in the webmail, Android, and iOS versions of Inbox.

We’ve also noticed that margin properties get stripped out if they contain negative values.

Media queries

The hero of Google’s announcement was media query support across all their clients. Media queries are useful for a few different things, but they’re mostly used for responsive design.

Media features Gmail webmail Inbox webmail G Suite webmail Inbox Android Inbox iOS Gmail Android Gmail iOS
min-width Yes Yes Yes Yes Yes Yes To be tested
max-width Yes Yes Yes Yes Yes Yes To be tested
min-device-width Yes Yes Yes Yes Yes Yes To be tested
max-device-width Yes Yes Yes Yes Yes Yes To be tested
orientation Yes Yes Yes Yes Yes Yes To be tested
min-resolution Yes Yes Yes Yes Yes Yes To be tested
max-resolution Yes Yes Yes Yes Yes Yes To be tested

Sure enough, our tests confirm support for the 7 promised media features across the board (in the clients we’ve had updated so far). That’s a solid set of basic features, allowing us to optimize for different viewport and device sizes, as well as landscape/portrait specific styles and retina optimization.

When optimizing a responsive email for different sizes, you have the choice between min-width/max-width and min-device-width/max-device-width.

Note that in Google’s three webmail clients, a min-width or max-width breakpoint applies to the full browser width, not just the width of the area where the email is displayed. This means the breakpoint will be negatively offset by the combined width of the webmail sidebars, compared to how a native desktop client would behave.

Whereas the min-device-width and max-device-width features are used to query the screen width, regardless of how large the browser window is.

Disappearing styles

Although Google’s email clients no longer strip out embedded stylesheets from the email’s <head>, there are still a few ways these stylesheets can vanish.

Overlimit stylesheets
When your email code goes through the preprocessor, it minifies your CSS and prefixes each class and ID with a per-email unique string.

The stylesheet is then checked against a 8,192 character limit. If your stylesheet, after processing, exceeds the limit, the whole stylesheet gets removed from your email.

Update: We originally reported the limit as being 10,000 characters, based on our tests. Thanks to Eric Lepetit at Nest Labs (a subsidiary of Alphabet, parent company of Google) for providing us with the accurate number from internal communication at Google.

If your email has multiple <style> blocks, they all get minified and prefixed the same way and then combined into one. The first stylesheet to push the combined size over 8,192 characters will be removed, along with any stylesheets after it.

This means that any CSS that needs to be rendered in Google’s clients should be placed in the first stylesheet of the email. That stylesheet should be kept well within 8,192 characters, allowing some extra characters for prefixing.

If you have other styles that doesn’t apply to Gmail, those can be moved to a separate <style> element below, so if something gets stripped out, it’s not something important.

Bad syntax
Playing fast and loose with CSS syntax can also get your entire stylesheet refused. An unclosed ruleset or a rogue * character and Gmail & Co. will discard the entire <style> block.

If your stylesheet is being ignored, validating your CSS is good place to start troubleshooting.

Replying and forwarding
When emails are replied to or forwarded, only the inline CSS is preserved in the quoted email. Both when testing in webmail and mobile clients, we found that the stylesheets were stripped out.

Display images below
When viewing an email with images off in Gmail, embedded styles will initially load correctly. However, if you click the “Display images below” link to turn images on, that causes Gmail to re-render the email markup with a different prefix for the class names and IDs.

The problem is, the email is still being styled with the previous version of the stylesheet, without updating the prefixes to match the current markup.

This means any CSS rule that depends on class name or ID selectors will stop working the moment images are turned on, leaving only element name or wildcard selectors.

Closing the email and opening it again will solve the problem for the recipient, if they happen to try it. Because all of Google’s clients now display images by default, this would only happen if the recipient has either actively disabled images, or if they are viewing the email in the Spam folder.

Thanks to Mark Robbins from Rebelmail for spotting and sharing this bug.

New emails in active Inbox thread
This one is less likely to happen in the wild, but was something we noticed while testing. If you’re viewing an email in Inbox and receive another email in the same thread while you have it open, the new email will appear unstyled at the bottom of the thread.

Outside of testing, it’s not that common for someone to receive multiple emails with the same subject line and sender, but it’s something to be aware of if the styles mysteriously disappear from the latest preview you sent yourself.

Once again, the solution is to close and reopen the email.

Is it the end of inline CSS yet?

When we first shared the news of Gmail’s rendering overhaul, we speculated whether we could now retire our CSS inliners for good. Among the major email clients, Gmail has long been the last outpost for <style> support.

The answer is a resounding “It depends.”

Is your stylesheet near or above the 8,192 character limit?

Does the “Display images below” bug or forwarding behavior concern you?

Do you need to support more obscure email clients without <style> support?

Do your emails get composed in a WYSIWYG editor where part of the formatting happens inline anyway?

Also bear in mind that although <style> support is widespread, selector support varies greatly. Yahoo! Mail doesn’t support double underscores in class names. Outlook 2007-2016 ignores class selectors if the element has multiple classes. misinterprets chained class selectors. A number of the pseudo-class and pseudo-element selectors are mostly unsupported.

If you plan to do away with inline styles, make sure your selectors work in all email clients you need them to.

For our Email Builder templates, we plan to review all CSS in an attempt to simplify and reduce the file size without rendering sacrifices in our supported email clients.

Targeting Google’s clients

When dealing with rendering bugs in particular email clients, the solution can often be specific CSS fixes targeted at those clients only. There’s no counting the number of Outlook bugs I’ve squashed with conditional comments.

For Google’s email clients, Mark Robbins from Rebelmail came up with a clever CSS hack:

<!DOCTYPE html>
<html lang="en">
u + .body .gmail{
display:block !important;
<body class="body">
<div class="gmail" style="display:none;">THIS IS GMAIL</div>

Any selectors prefixed with u + .body will be read by Google’s clients, but ignored by every other email client.

The secret behind this hack is in Google’s preprocessing of the email’s markup. The <body> element is changed to a <div>, but its class name is retained and prefixed for us to target.

The empty <u></u> element actually derives from the doctype, which does not get preserved in the email. Thanks to Rémi Parmentier from Tilt Studio for pointing this out.

Because Google’s clients are the only ones to replace the doctype with a <u> element, the u + .body selector ends up matching an element only in those. The hack targets all of their email clients but can be combined with media queries to distinguish between mobile devices and big screens.

Wrap up

It’s an exciting time to be an email developer and see these changes we’ve dreamed about for years finally coming to fruition. Interactive email has taken a small blow with this update, but overall this is a big step forward for Google’s email rendering.

Have you noticed anything we’ve missed? Let us all know in the comments below.