Should we stop inlining styles in emails?
Until last year, Gmail was one of the biggest email clients that only supported inline styles. The webmails of Yahoo, AOL, Outlook.com and, yes, even the desktop versions of Outlook using Word’s rendering engine (from 2007 to 2016 on Windows) have all long supported <style> tags. The 2016 Gmail update was a total game changer and finally added support for <style> tags as well as for class and id attributes. So is 2017 finally the year to stop inlining styles?
This question rose again last month when Litmus’ Kevin Mandeville shared insights about why Litmus didn’t inline CSS for its first newsletter. While this makes a lot of sense for Litmus and their audience, and they did a great job at providing a gracefully degraded version, I’m not sure it is time to advise to stop inlining styles for the whole email development industry.
Here are a few things to consider, pros and cons.
Not all email clients support <style> tags.
A lot of international email clients don’t support <style> tags. Clients like Libero (in Italy), Mail.ru or Yandex (in Russia), Nate or Naver (in Korea), T‑online (in Germany), Telstra (in Australia) or Terra (in Brazil).
Sometimes it also happens only on some versions of certain international clients. In France, the iOS app of SFR or the Android app of Orange don’t support <style> either (while their other desktop or mobile counterparts do).
But above all, even Gmail, Yahoo or Outlook.com sometimes don’t support <style> tags. This is true for Gmail on Android with a Non Gmail Account (aka GANGA), Yahoo on their Android app or mobile webmail, and Outlook.com on mobile on their old webmail (still available for some users in Europe).
Email clients have their own default styles.
This is especially problematic within webmails, where your HTML email will inherit from too generic styles of webmails. For example, the desktop webmail of Gmail has the following CSS rule for its UI that changes the default blue of links.
.ii a[href] {
color: #15c;
}Because it’s a very generic rule, it will apply for links inside your emails. Because it’s also a specific rule (targeting a class name, a tag name and an attribute name), you can’t simply override it with a generic a {color:inherit;} style. And because Gmail doesn’t support attribute selectors, you can’t use a a[href] selector. This doesn’t mean it can be solved with a more specific selector. But you’ll need to repeat this for every email client default styles.
One unsuspected advantage of inlining styles is that it overrides email clients default styles automatically, without requiring you to spend hours inspecting every email clients.
It makes your code lighter.
This is actually a huge argument in favor of not inlining styles. I ran a quick comparison on Litmus’ own newsletter. Sent without inline styles, the email weighs around 58 Kb. With inline styles (automatically generated by Putsmail), the email would weigh around 73 Kb. That’s a huge 25 % difference!
A lighter HTML means it’s faster to initially download. But it can also help avoid having your emails clipped by certain email clients. For example, the desktop webmail of Gmail clips any content after the first 102 Kb of an email. A subscriber has to click on a “View entire message” link in order to display the email entirely.
However, not inlining style might become counter productive for elements that only appear once in an email. A class attribute plus a <style> declaration will weigh more than a single inline attribute.
Inlining styles is a pain in the ass.
Is it, really? I mean, if you come from the Web development world, it sure is one the first quirk of the Email development world you’ll notice. But in the email world, we’ve been inlining styles since the beginning. Using your own snippets, tools like Emmet or one of the many inliners out there makes this pretty much painless.
There might be other arguments for or against inlining styles in emails. But I’d like to end this article with something I wrote on my french blog five years ago.
The Email Developer Mantra
Whenever I code, may it be for the web or for emails, I always come down to one question…
What’s best for users?
I need to code a carousel for a homepage. I can search the Web for one already existing that will fit my need. Or I can code one myself. What’s best for users?
The designer used funky fonts for this email. I can code this email with all the text in images. Or I can embed the font in CSS and set the text in HTML, knowing that this won’t work in every email client. What’s best for users?
Not all email clients support <style> tags. I can inline all my styles. Or I can just make sure the email will gracefully degrade and render as good as it can on other email clients. What’s best for users?
The beauty of this question is it doesn’t have a definite answer. What works for some projects might not work for others. What works now might not apply for the future.
So while I’m not sold on the idea to stop inlining for the emails I work on, I’m excited to know this is something I can now consider.
