Why don't email clients use modern rendering engines?

Question

It's 2017 and we are still stuck with HTML tables to create rich emails. Why? It seems reasonable to leverage the hard work behind the modern browser engines (ie. blink), when all you want is to render an HTML document properly.

Answer 1

Update: Since this question was closed and my answer resembles a blog post, I published an updated version on Medium.

---

Email clients use rendering engines appropriate for displaying emails. This is not always in step with displaying web pages.

Only a small % of email users care about HTML/CSS support. Think email marketers and developers. The vast majority of email users simply want a simple, secure way of sending and receiving rich text messages with other people. That’s what email clients are designed for.

Even more advanced users don’t often cite good HTML/CSS support as a top concern. Recent innovations give us a little insight as to what folks are frustrated with regarding email clients: help managing incoming messages, more security, less SPAM, and overall ease of use.

No one cares if it takes developers a long time to use <tables> and inline CSS to create an email. When it comes to changing how emails are rendered… “If it’s not broke, why fix it?” When email clients actually do update rendering, it’s rarely news outside of the tech community. Few people care.

Consider Desktop Outlook, which typically comes bundled with programs like Word and Powerpoint. All these programs have a similar interface and display output. If you can author a Word document, there’s almost no learning curve in writing an email in Outlook. That’s huge for a lot of people. In all likelihood, Outlook’s rendering engine wasn’t chosen based on it’s ability to render an HTML document properly, yet the product is still considered a success. Because desktop Outlook and doesn’t get automatic updates, old versions (that we have to code for) tend to hang around.

Fun fact: Outlook 2000-2003 rendered email using whatever version of Internet Explorer was installed locally the computer to render email (usually Internet Explorer 6).

Gmail is another example. While Gmail has pretty good HTML/CSS support, it didn’t support external CSS files until late 2016. Gmail (unofficially) cited security as one of the reasons. I don’t know what keeps the Gmail team up at night, but I bet it’s not how email developers can’t optimize their email layouts. I bet it’s security. And so that’s where the gmail dev work gets focused.

Overall email clients do their job relatively well. Since HTML/CSS support matters to so few people, changing it is likely not often a priority for product teams that make email clients.

---

However, things are trending in the right direction. Gmail and Yahoo! app began supporting media queries in most of their products. Outlook on iOS got a huge facelift including good markup support. New email clients that crop up (Mailbox, Nylus. Polymail) generally have good HTML/CSS support compared to the web. Rarely does support go backwards. The majority of clients based on market share use “modern rendering engines”.

Additionally we can always reference our own email analytics. Don’t have many Outlook subscribers? Then code an email using <div>s. Don’t need to support every mobile client? Then use media-queries.