E-mail: The Next Frontier for Web Standards

Today is the 7th annual celebration of Blue Beanie Day, a yearly effort to support web standards. These days it is hard to imagine a world before strong web standards were the norm – building websites was infinitely more tedious, messy, and inefficient.

Luckily, we now live in a world where browser support for web standards is largely the reality. For the most part, the experience of building a universally accessible website today is decidedly less maddening than it was during the Browser Wars.

Web Standards Support (and the Lack Thereof) for E-mail

On this 7th annual Blue Beanie Day – more than 15 years after the start of the web standards revolution – the state of HTML-based e-mail design is dismal. Image slicing and table-based layouts are still the norm, despite the universal understanding that such practices are bad. Inline styling is standard practice to prevent design instructions from being stripped away in many places. Support for media query functionality which is fundamental for most new websites today isn’t even close to reliable. And if that weren’t bad enough, e-mail designers still can’t use webfonts and expect all their audience to be able to enjoy the results.

The Vicious Circle of Non-Standard E-mail Design

The unfortunate reality of the situation is a cyclical conundrum: If everyone keeps bending over backwards to compose e-mails that will work with non-compliant e-mail clients, we will be stuck doing so forever. Naturally, every designer wants their e-mails to be seen as intended in as many places as possible, but the makers of e-mail clients don’t have much incentive to become standards compliant unless their product fails to be usable otherwise.

In essence, the support for web standards in e-mail clients is still stuck somewhere in the late 1990s. This is not OK. Something needs to change.

Embracing Web Standards in E-mail

Earlier this month, we launched the inaugural edition of Webtype News, our e-mail newsletter about new webfonts, site updates, examples of webfonts in use, etc. When it was time to discuss the format and composition of the e-mail, we came up against the same questions that most e-mail designers do: How much time should we spend working on hacks for non-compliant e-mail clients? How much can we rely on media queries? When people’s e-mail clients don’t support modern web standards, what are the implications of encouraging them to read the e-mail as a separate stand-alone web page?

Eventually, after much deliberation, we decided that the best way to encourage support for web standards in the realm of e-mail was to embrace the standards ourselves. Inspired partly by Jeffrey Zeldman’s exclamation of To Hell With Bad Browsers from 2001, we decided it was about time to say “to hell with bad e-mail clients” too. We composed our new e-mail using modern web standards, including media queries, proper cascading stylization, and — most importantly for us — webfonts.

This approach to e-mail design is admittedly progressive, but at the end of the day we thought it would be much more rewarding to see what is possible when you compose e-mail around web standards instead of code hacks and design compromises. Some e-mail clients do in fact support a majority of web design standards, giving us hope for what is possible. (Sign up for the newsletter if you want to see what we do in the future.)

We don’t expect that every e-mail designer in the world will be able to take the same approach that we’ve taken right away, but we’d like to encourage more people to at least consider how they might start experimenting with e-mail design in ways that will encourage a broader adoption in e-mail clients. Such a change is long overdue.

Nick Sherman

5 Responses to E-mail: The Next Frontier for Web Standards

  • As someone who has written professionally about network and computer security since before the end of the last century, and has guest-lectured on computer forensics and computer fraud at university Forensics BSc and Law degree courses, here is my take on it.

    email is not an area awaiting a web standard – it is not part of the web, it is part of the Internet as a whole and is covered by rfc 2821.

    The risks associated with using HTML in email are so bad that I would never recommend using it. e-mail is plain-text only – that is the safest way. HTML has been bolted onto it to make it look pretty; and it has been moved into your web browser so that you don’t need a special piece of client software to access it but by doing so, but has basically buggered your security.

    Once you start using HTML, you find that your Windows or Mac is turned into a porn server (child or adult) or it has become part of a botnet that can be used for all manner of illegal activities without the user even being aware of it. You might think that your internet connection is a bit slow sometimes but in reality, it is because people all over the planet are downloading files from it or it is being used to attack a bank or government site somewhere.

    With plain-text, you see what there is. You have the option to open any files that accompany the mail – note that it is not compulsory to do so.

    With HTML, it looks pretty and everything is done for you so when your mail program (yes, even a web-browser for web-based e-mail) opens some attachment or other, for you, you have no idea what is going on. HTML mail is used every day to take over people’s computers by exploiting flaws in the software that opens them. With plain-text email, what you see is what there is.

    • You could say the same of browser security in general. There are always going to be attempts to take advantages of flaws in software—I don’t see why an HTML document that’s increasingly going to be viewed in a standard browser shouldn’t follow the same standards as the rest of the web.

      If you’re arguing for plain-text email as a safety procaution, it’s the same as arguing for the entire internet in plain-text.

    • This really interests me. Would you be able to elaborate as to why an HTML email is more dangerous than a website? Is it purely the delivery of it?

      Email clients already massively restrict what we can do with HTML. Last year Outlook decided to stop supporting margins. What harm can possibly be done with a margin?

      The best email developers I know are hacking away at HTML to make the most simple functions work. Surly it’s not HTML to blame but the email clients accepting other scripts.

  • Whilst I agree absolutely with Paul Grosse, the fact is that we are in a microscopic minority. The rest of the world isn’t going to change.

    Paul’s prediction of doom are real possibilities but until it happens to them they’ll not take the precautions.

    There is a parallel with password choice, tell people it matters ’till you’re blue in the face and you still find they use 123456 for 57 different services and if you masquerade as “technical support” they’ll tell their password anyway.

  • Thanks for sharing your take on this.

    In terms of the vicious cycle that you’ve illustrated, I honestly don’t think email client developers are even thinking about email developers at all. Their primary concern is that their programs send and receive rich- or plain-text emails and attachments.

    Web pages in HTML make up 95% of what most users experience as “the internet” and so there is some leverage there for web developers to be able to tell users to upgrade their browser, especially since browsing the internet is an active endeavour.

    Receiving HTML emails, on the other hand, is passive and may only make up about 20% of what most users experience as “email”. The point of signing up to an email newsletter is so that you can quietly accumulate updates without having to go looking for them. If someone sends an email that requires active participation to even see the content in the first place, that defies the whole point, and is a huge barrier that would deter most users.

    Another sad reality is this: even if all the email developers in the entire world stopped supporting email clients without proper standards (which is 99% of them), it would hardly cause any kind of fallout. It would simply result in emails that look ugly in most email clients (which, we know, simply leads users to delete them). And where one can reasonably ask someone to update to a modern browser on the web, for the millions of people using Microsoft Outlook, even upgrading to the latest version does not help, since its HTML rendering engine (Word) yields poorer results than the engine in Outlook 2003.

    Using HTML in email has always been shoehorning something into where it doesn’t belong. From my perspective, there just isn’t enough leverage to try to launch any kind of resistance to the state of things at present.

    Now that more than 50% of email consumption is happening on mobiles, the future isn’t too bleak, and we can look to a (fairly near) future where we can build emails using web standards. In the meantime, I feel that offering an experience that degrades gracefully is the best thing to do.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>