
Here's why Litmus didn't inline CSS for its first newsletter of 2017
Hey all!
We just sent out the first Litmus newsletter of 2017 (you can see it here in Builder). We like to experiment with new design and coding techniques in our newsletter, and this month we tried something new (and possibly radical).
We did not inline the CSS for this email. We only used a couple of inline styles to restrict the email width and center the email content. For users opening in an email client that doesn’t support embedded CSS, they essentially received a plain-text like version of the email (you can see an image of it here).
With Gmail's rendering update to support embedded CSS, essentially the entire global email client market share (95%+) now supports embedded CSS.
Granted, there are still some edge cases where Gmail accounts do not have the update, such as non-Gmail accounts (@outlook.com, @yahoo.com, etc.) in Gmail App. However, when we used Litmus Email Analytics to analyze our own audience we found those users to essentially be non-existent (less than 100 opens per send). Several international webmail clients (Mail.ru, Yandex, etc.) still don’t support embedded CSS either, but most of our audience doesn’t open in those clients.
Our generic audience breakdown at Litmus currently is:
- Apple Mail ~30%
- Gmail ~30%
- Outlook ~15%
- iPhone ~12%
- Web version ~5%
- iPad ~1%
- Android ~1%
- All others < 1%
Given our audience makeup, we decided to start testing embedded (non-inlined) CSS. This has the benefit of creating more accessible emails with semantic markup. Plus, it comes with many development benefits in terms of organization, maintenance, and flexibility to more easily use progressive enhancement.
For clients that did not support embedded CSS, we added a special preheader message explaining why the email may look a little different and pointed them directly to this thread for more information.
We’d like to understand your reaction to this approach, and we’re hopeful we’ll be able to move forward with a similar strategy for email development at Litmus.
What are your thoughts?
- Do you plan to stop inlining CSS for your emails in 2017?
- Do you like this approach?
- Did you open this email in a client that didn’t support embedded CSS?
Hey Kevin ! Thanks for leading this experiment, and thanks for sharing this with us. I ran a few tests with your email and saw minor caveats where the webmail's own styles seem to override your own styles. For example, here on french webmail La Poste.
Overall, you did a great job at providing a graceful degradation. And the fact you still use
<table>
for most of the layout (like the icons next to each of the top 10 articles) helps this. But I'm definitely not sold on stopping inline styles.The question that haunts me is: what benefits does it give to your subscribers? The major upside that I see is it helps create lighter HTML emails. I ran a quick comparison: without inline styles, your email weighs around 58 Kb; with inline styles (with Putsmail), it would weigh around 73 Kb. That's a huge difference that might be worth it for special case.
However, I strongly disagree with your argument that this helps make email more accessible. Semantic markup makes emails more accessible. Meaningful alternative text makes emails more accessible. But inlining styles has never made email less accessible. I'm afraid you're giving the impression that just stopping styles inlining will magically improve email accessibility, which is false.
Finally, I'm not sure we should only follow email opens statistics to make these kind of decisions. I like this quote from a recent Apple engineer article.
I like this idea that we can still take care of even the smallest minority of our users if it makes sense for the brands we work for.
Overall, I'm really interested about the evolution this can bring to emails. But I'm convinced this is not a case of all or nothing. The way I envision things is to add a few styles setting typography and colors inline, while most layout might be done in
<style>
tags.Analysing your list should be the first step. Know your audience and then communicate with them. If for example I know that my list is 95% apple users why should I use inline styles? I think moving forward people will stop using the old clients anyways. You mentioned 58Kb to 73Kb. Depending on the size of the email that could get bigger. I am personally a big fan of getting rid of the inline styles. But maybe its a bit too early. Thumbs up for Litmus though who dare to experiment.
Plus one for your accessibility argument. Less inline-styles doesn't help there.
I like to send beautiful looking emails to e.g. lotus notes users, although they might be a minority. But sometimes it's just about saving Kb - like for an audience which opens their emails mobile and with bad internet connection. In this case the approach is a pretty useful.
Great work Kevin,
I think the main thing to consider is how the fallback looks, and it's not too bad, it's still very functional. I'd be tempted to move some more basic styles inline to give a slightly better experience in these places. But its down to preference. I think this is a solid proof of concept.
One thing I would note, there are a few places where adding styles in the head takes up more space than inlining.
For example this is only being used once so could have been applied directly to the
<img>
tag.Although depending on how you build this might be easier for reusable templates.
Also following on from what Rémi said about file size, I noticed there's quite a bit of unused CSS so could potentially get the files size a bit lower than 58 Kb
This leads me to a small concern I have going forward, if we all make the jump over to styles in the head there is the risk of larger files sizes made up of redundant and unused CSS, styling for every eventuality even is the related content isn't in the email.
It's a common issue for web developers, and there are a number of ways around it. As i say it's only a small concern, if we're aware of it from the start it's very manageable.
Hi Kevin - it looked good in the Gmail app on my Android 6. It did not render the CSS version for me in Gmail/desktop. The following are probably edge cases, but it also didn't display as desired in Yahoo App; and on OWA, the images extend outside the email width - especially when viewed on the phone.
I will continue to inline CSS until I'm 100% sure it will look good on almost all emails clients.
Hi I'm CTO of mail service at Mail.ru. We are planning to support inline CSS.
And we are looking for beta users to try it. If you want to try and send feedback please tell your mail.ru mailbox.
Hi Andrew, I'd be interested in being a beta user. My address is rebelmailtest@mail.ru
Thanks,
Mark
Mornin,
could it be that you do not suport custom Pre- Headers any more? The handy display:none; dont work for some reason =/