Ever wondered why newsletters look a certain way in Gmail, then slightly different in Google Apps? As it turns out, they’re two unique email clients, as far as CSS support in email goes. Here’s what we’ve seen so far.
Before we get into the thick of it, there’s a little back story to be had. I was a speaker at the excellent Email Design Conference in October last year and over the course of the event, was doing a little testing on a responsive email design in Gmail. While it’s fairly common knowledge that Gmail does not support media queries in email, something caught my attention – a small set of attribute selectors were being applied, even when styles were not moved/copied inline. This totally caught me off-guard – in theory, Gmail ignores all CSS styles in <head> and you know, for email designers, that is that.
After a little more testing, I noticed something even stranger – there were differences in results between how my Gmail (@gmail.com) account was applying CSS styles and how things were turning out in my Google Apps (@mysite.com) mailbox. While certain attribute selectors were being applied correctly in Gmail, there would be no result in Google Apps.
I could have just dropped the case, outright declared that Gmail/Google Apps was broke and all email designers should just write off CSS styles, unless they can be inlined. But then the customer emails started coming in.
But, you can totally use CSS styles now!
As it turned out, I was not the only one who noticed the oddities. Not long after these tests, we received an email mentioning that the results in our Guide to CSS Support in Email were incorrect and Gmail was indeed supporting attribute selectors. While I had nothing yet in our docs to support it, I ran a few more tests and again, Gmail was supporting a set of selectors, but Google Apps was not. A few months later, I refreshed our results during an update of our Guide and found that fewer selectors were being supported this time (namely * and E > F). Then just today, another customer alerted us to something odd – Gmail was supporting CSS styles in <head> – but as it turns out, only for elements, not for classes. As before, results came up negative for Google Apps.
What does this mean to email designers?
treat Gmail and Google Apps as separate email clients when testingThe main takeaway we got from ongoing testing is that Gmail’s email rendering capabilities are a shifting landscape. Twice over in the last 6 months we’ve had to update our Guide to CSS in Email to reflect the quiet changes that have occurred – and continue to occur – as Google iterates on their email client. Secondly, we now encourage email designers to treat Gmail and Google Apps as separate email clients when testing. The difference between a style being applied in one client, but not another can be fairly pronounced. Finally, we can’t stress enough how important it is to keep copying/moving your CSS styles inline, either when importing a campaign into a service like Campaign Monitor, or by using a tool like inliner.cm.
You’ll notice that we’ve added tooltips to results in our Guide to CSS Support in Email to reflect these rendering differences – and provided a negative result for <style> in <head>. At a later date, we may make an explicit distinction between Gmail and Google Apps as far as support for styles in classes vs elements goes, but for everyone’s sanity, we’re recommending that folks treat support for CSS styles in <head> as an edge case, not a rule.
A cheeky shout-out: Nicole Merlin and myself will be hosting discussions on email design and rendering oddities like this one at The Email Design Conference in Boston on 18-20 August. Come along and nerd out over email with us!