The current state of email clients is such that responsive email is considered one of the most difficult tasks in web-development. It’s time to force the hand of email client developers.
In 2001 Jeffrey Zeldman wrote:
[Web] standards have been around for years. Browsers that support them have been around for six months to a year. If not now, when?
It typically takes 18 months or longer for web users to upgrade their browsers. Many still use browsers, like Netscape 4, that date back to 1997. These folks will only upgrade if we give them a reason to do so.
To hell with bad browsers, A List Apart
When Zeldman wrote the words above, browsers were leaving behind a period of competing on proprietary features. Today, support of web standards is embraced by the companies developing browsers; it’s how the browser manufacturers compete today.
In my talk at Web Directions Respond earlier this year, I credited Zeldman’s article with helping create the browser environment of today. The web developer of the early 2000s took his message and ran with it, standards were embraced by web developers, forcing the hand of browser manufactures so web sites worked and looked decent in their browsers.
It’s time to force the hand of email clients
A friend recently posted the ludicrous closing code from a responsive HTML emailer he was coding on Twitter.
</td></tr></tbody></table>
</td></tr></tbody></table>
</td></tr></tbody></table>
<div class="footer" style="font-size:8px;line-height:8px;"> </div>
</td></tr></tbody></table>
</td></tr></tbody></table>
</center>
</td></tr></tbody></table>Both the major email provides, Campaign Monitor and MailChimp, have developed tools to help developers produce such shambolic code. MailChimp goes so far as to claim it’s to help send better email.
It’s not better, it’s accommodating.
It’s time to stop accommodating bad email clients, there are email clients that support something representing web standards. Developers should code emails for those clients, poor quality clients will be forced to catch up.
Every table you add to an emailer makes it less future friendly. Each upgrade to email clients, each new email client will require you waste time and money going back to check your email still works – adding more and more unsemantic code to fix it.
As web developers, we’ve dealt with differing CSS support before. We still do. Progressive enhancement works for websites, it will work for email clients too.
Why would my company do this?
Upward management is a long standing tradition of employees, make your employers and clients aware of how much supporting crappy email clients is costing them. Make your employers and clients aware that you can make emails look good enough in bad email clients and enhance them for modern clients.
In summing up his article in 2001, Zeldman wrote:
Your company’s survival is tied to the ability of the products it makes to work in situations you haven’t imagined, and on devices that don’t yet exist. This has always been the challenge of web design.
The same applies to email. Crippling your code from the start is to code for the present, Moore’s law tells us the need to update your code will become more frequent, and will cost more money in the long run.
It’s a nice thought but entirely unrealistic. There are so many more email clients than popular browsers to contend with and using tables ensures that we’ll have a more consistent layout. Outlook (all versions even up to 2013 last year) are utterly shitty with ul’s and ol’s and padding setups – we’re supposed to just ignore that are we?
If I told a client I was only going to make an email that displayed properly in a couple of email clients they’d ask “Well what are we paying you for then? We could do that ourselves…”.
“Well you know we don’t want to be seen to be supporting the old email clients because we want to have the future now…”
Emails are here for a good time, not a long time. It doesn’t matter if they don’t work properly in 2 years time. It matters they work NOW.
Exactly right.
I disagree, this is the same argument used in the early 2000s to justify table-based layouts, font tags and other non-standards based development.
I’m advocating for progressive enhancement in email. Quality email clients get a feature rich experience, poor quality email clients can read the content but miss out on some of the shine.
This is a widely accepted – even embraced – practice in the browser. We can extend it to email.
This is a widely embraced practice browser nowadays because more than 90% of the most used browsers are modern browsers that allow web developers to get away with this.
In the email world, it’s the exact opposite. 90 % of the most used email clients are atrocious at rendering HTML and CSS. So, you want to stop supporting bad email clients ? Fine. Your emails will look like crap on Outlook 2007, 2010, 2013 and even the latest Outlook on Windows 10 (which all uses Word’s HTML rendering engine), in Gmail (which doesn’t support anything but inline styles on mobile), in Outlook.com (which only supports properties like
marginorpositionwhen they’re written with an uppercased first letter), in Yahoo (which doesn’t support attribute selectors or anypositionproperty). What do you end up with ? An email that will look fine only in Apple Mail. Or the equivalent of web developers building websites for WebKit only.I’m a strong advocator for building emails with semantic markup and with progressive enhancement in mind. And time will come where this will be the standard practice for email developers. But we’re not just there yet.
I agree wholeheartedly with Becs and Rémi. When you take progressive enhancement to its logical conclusion in email you don’t just end up with the lowest common denominator missing some ‘shine’, they will look completely and utterly broken and make the sender look incompetent. Some of the ways that these clients render HTML is beyond comprehension so the ways in which emails can break are spectacular.
Email is also quite a passive experience whereas using the web is an active pursuit. There is much less cause for an email subscriber to care if the HTML emails they receive are bad.. they just delete them. People actively browsing the web will be saddened to read that their browser is not supported and that therefore they are getting a sub-standard experience. They are motivated to upgrade. I don’t think you could say the same for email users, not least because the cost of switching is so much higher.. for webmail users they’d have to get a whole new email address.
Hi Peter, Thank you for the feedback. I’m a PM on Outlook, and we are listening. In fact, we are currently looking into ways that we can make the beautiful HTML emails you guys create look better in Outlook, as Justin mentioned (http://freshinbox.com/blog/the-outlook-team-reaches-out/). Once I have something I can share publicly, I will. In the meantime, please feel free to reach out with questions.
This whole article is based on the assumption that a ‘good’ email client renders HTML as good as (or close to) a browser. But why?
Somewhere along the way we seem to have forgotten the distinction between an email and a web-page and in doing so we’ve manufactured the notion that email clients are broken / need fixing. My SMS app doesn’t support HTML but another persons does – is mine now broke?
I’d encourage anyone who disagrees with the above to try staying in a country with slow (worse than dial-up!) internet which costs a fortune per MB. Checking email becomes not only frustrating but seriously expensive. In fact – email becomes actually broken.
I’m a bit split on this one. I’m all for pushing everyday users behind better standard but I’m not comfortable with dropping support for such a large market.
I suppose it could be (very roughly) compared to something like . Would you use a element on a website with no fallback or would you use a pollyfill, which could be seen as unnecessary JS bloat?
My preference would be progressive enhancement, offer more to the consumers who have modern email clients rather then less to those that don’t. Rewarding rather than punishing.
Outlook users will likely see these enhancements via their personal webmail or a mobile email client. This is something that didn’t really apply back in 2001 people would likely use one (maybe two) browsers so less likely to see a difference.
I’m talking about visual enhancements here rather than architectural, things like animation, interaction, SVG, webfonts, etc. Something a user will see an improvement in, something that could make them complain or more likely upgrade.
Cheers,
Mark
I agree with your sentiment but don’t know if this is the way to go about advocating for the change.
I am 100% for progressive enhancement so long as an email doesn’t outright break. I think this is a pretty safe stance to take with client work. I see examples of this all the time with typography, animation, and interactive click experiences. Happens on the web too, as well all know.
But you lost me when you suggested dropping tables, since that would outright break most emails everywhere. On the web, it would be akin to dropping s and going with HTML5 tags like without polyfilling old browsers. Everything becomes unusable for that poor guy at work who can’t upgrade his software.
You’ve been in the web game for a while, you know this.
Perhaps something in the middle is more practical. There’s a minor breakage in Outlook. Animations don’t play. Mobile Gmail isn’t responsive. That sorta thing… where the experience is better/faster where for clients that support it, and still passable in old clients.
There was outcry for years for people up upgrade from old browsers. And it happen, but *really slowly*. I’d imagine email clients would follow a similar pattern, wouldn’t you?
this is something we’ve discussed a lot in the email community. We’re between a rock and a hard place – clients want things to work everywhere, so we have to code this way to get max support. I do believe it’s fundamentally different to the web standards movement though, in terms of scale and in terms of email’s nature.
I wrote a longer piece here – http://www.emaildesignreview.com/html-email-coding/will-there-ever-be-an-email-standard-2707/
Personally, I couldn’t give a flying ferret about HTML in email anyway. I have my email client configured to ignore it and just show the text component. Email is email and I’ve never seen one that’s in HTML that’s in any way more valuable or useful.
I agree with the article and think that a progressively enhanced email would be possible, it would just have to be a single column layout with full width images, but that’s kind of what works best in email design anyway because the viewport is usually so small…
I think a lot of problems would be solved if we could fix two problems: First, make media queries work for every mail client from here forward, so we can eventually phase out email clients that don’t support them. Second, get rid of Word rendering engine in emails entirely. I read recently that Microsoft has decided to keep using Word rendering engine for Outlook 2016, so it doesn’t seem like they are ready to catch up with the rest of the world. When all of those MSO exceptions are gone and media queries work, we will have much better looking emails. Those two items are the only things I fight with when creating responsive email.