Here's why Litmus didn't inline CSS for its first newsletter of 2017

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.

Back when I was running most of Apple’s e-mail systems for the marketing teams, I went to them and suggested that we should consider dumping the text-only part of the emails we were building, because only about 4% of users used them and it added a significant amount of work to the process of creation and testing each e-mail.

Their response? That it was a small group of people, but a strategic one, since it was highly biased towards developers and power users. So the two-part emails stayed — and they were right. It made no sense from a business standpoint to continue to develop these emails as both HTML at text, but it made significant strategic sense. It was an investment in keeping this key user base happy with Apple.

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.

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.

.hero-img {
    display: block;
    border: 0px;
    color: #5b5b5b;
    border-radius: 3px;
    box-shadow: 0 0 25px rgba(0,0,0,0.2);
}

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.