TL;DR:

TD,TR aren't good, but we're stuck with them.

As you may or may not know, the HTML standard for email is a mess.

There is no defined standard, it is more a way of coding that is a reliable as we can get in as many email platforms as we can.

It is easy to dismiss it as coding for 1995 – and the table based approach has its roots from that era – but there is at least a dash of some more modern code in order to apply fixes and add enhancement.

Why so bad? The main perpetrators of bad support at this point are Gmail (both web and app) and installed versions of Outlook.

At the last count, Gmail has around .9bn users, 75% of which are on mobile.

18% of marketing emails are opened in Gmail (an aggregate of Litmus tracking , of course your mileage may vary).

On average 8% of marketing emails are opened on installed versions of Outlook (mainly 07/10/13).

That is quite neatly a quarter of all email opens happening in a sub-standard environment.

The other email clients have their nuances but by and large they’re not too bad in terms of HTML support.Gmail effectively strips out the style tag, making CSS based layout impossible and forcing all style to be coded inline.

The apps do the same, so have no support for responsive design.

Outlook uses the Word rendering engine (apparently to maintain consistency with the Office suite), which has very bad CSS layout support, forcing us to use tables for layout instead of CSS.There is fairly good support for more recent code techniques in various other email clients, particularly iOS devices, but our need to maintain support for Gmail and Outlook restricts their use.

These two clients are holding back the entire eco-system, and the net effect is there is no modern standard for email, in the way the web has.

The web email standards movement Here’s the problem.

In the early 2000s there was the web standards movement, which were a direct result of the browser wars – a kind of cold war for HTML support between Netscape and IE.

As a result of the web standards movement, HTML code support was mostly standardised between browsers, and with that more intuitive, powerful and semantic code methods were supported.Email does not have that, and it will be incredibly difficult for this to happen.For a start, the browser wars were between two browsers.

Even now, much of the web is seen through a handful of very good rendering engines.

Email is viewed in 1) desktop clients, which have a much slower update cycle 2) a much wider selection of mobile apps and 3) a large combination of browsers viewing various webmail platforms.

Various spam filters can also change HTML, and even the email sending platforms, who you'd think would know better, have their own way with your code.

All of these environments affect HTML support.There is also a large safety consideration, as email is pushed rather than the web being mainly pull.

It doesn’t do anyone any favours to allow mailed CSS to hijack a webmail interface, for instance.

This is mainly the reason why javascript and flash are not supported.And lastly, where’s the desire? as email designers it would be great to drive proper support for decent HTML, but to what end? to facilitate a bunch of marketing messages? Google, let’s not forget, is a large marketing company itself – and it’s not difficult to see why it’s not high on the agenda to improve support for marketing messages they don’t see any revenue from.

Microsoft recently reached out to the community for help improving support in the new breed of Outlook clients – which is to be applauded – but it will take years for the inertia of Outlook 07/10/13 to be overcome.

I had lunch recently with a sysadmin for a large bank, who told me that they intentionally have to install versions of software 2-3 versions back – under the fairly mistaken impression that older software has had more bug fixes.

Our clients don’t really care either, and neither do the audience.

It's hard to quantify whether more people buy from a marketing campaign as a direct result of the HTML being better – though better support does mean an improved experience and increased accessibility, so it probably does lift the result somewhat.

What can we do? Should we code modern HTML and to hell with Outlook and Gmail? the problem is that’s 26% of the audience.

Try telling a client you’re going to intentionally not support 26% of their customers to make a point.

There's a scale of things we can do to support these clients, but the most advanced ( the Hybrid Approach ) can add significant hours to a project.

Do we need a standard? absolutely. Should that be HTML? probably.

An email specific standard has some benefits, but the need to support both whilst the multitude of email clients catch up will be too messy.

There are various efforts – the W3C has a working group and individuals have raised the discussion with Gmail .

There is lots of discussion on Twitter and the Litmus Community .

Email isn’t going to change overnight, but the time to start that change is now.

So where do we start? More reading Hybrid is the answer, is it the right question What does a modern HTML framework look like in email? If you're still not put off, we'll teach you email code