About the
Email Standards Project

The Email Standards Project works with email client developers and the design community to improve web standards support and accessibility in email. Read more »

Blog Archives

Blog Categories

RSS Feed

ESP Blog Feed

Recent Entries

Email Standards Project — answers to common questions

Posted by Mathew Patterson on December 4, 2007 in

Since the Email Standards Project launched last week, we’ve had a ton of great, supportive feedback, a fair amount of healthy scepticism and some toasting warm flaming. With a topic like HTML in email, it was inevitable that there would be some controversy surrounding it.

With this post, we want to address some of the questions that have been raised, and clarify exactly what the Email Standards Project is and is not about. We welcome your feedback, so read on and comment below.

But email was never meant to be HTML!

It’s true that email was not originally designed to carry and render HTML. It’s true, but it is not particularly relevant today, because all the major email clients support HTML and many use it as the default format.

Tim Berners Lee came up with the idea of the web as ‘a system to communicate information among researchers in the CERN High Energy Physics department’, but you don’t see people arguing we should still stick to that.

We’re not here to say that everybody should send HTML email, or that it is a better way or the future of email. The Email Standards Project is about recognising reality: HTML email is here to stay, and it has some problems which we think we can help fix.

Some people think that we should instead be working at stopping email clients from supporting HTML, and stopping people from sending it. We think that’s an exercise better left for other people to attempt, and one very unlikely to go anywhere.

Plain text is better than HTML anyway

Here’s the thing: It doesn’t matter if you or I prefer plain text to HTML email. As web designers we are not representative of the wider email using audience, and we don’t have the right to tell them all what they should and should not like.

We can and should always demand the right for each person to choose their own format; everyone should be sending text+html so that the recipient can view email in the way they prefer.

We should not attempt to force our preference on to other people who don’t have any philosophical problems with HTML in email, and don’t care about our distinctions between a web browser and an email client.

The Email Standards Project is not saying you should always send HTML, it is saying ‘when we send HTML email, it should be consistently rendered using modern web standards for the best results.

Just send your HTML page as an attachment or link

This seems to be a common solution offered by people who dislike the idea of HTML email. It’s one that seems like a compromise position, but that really offers very little.

Jeffrey Zeldman echoes our own feelings on this in reply to a comment on his site:


Many corporate mail gateways block attachments; many even block e-mails with attachments (not just the attachments).

Assuming an attached HTML file gets past the gateway, you now have to rely on the recipient’s expertise. He/she must know what to do with an attached HTML file (i.e., drag it into her browser).

You’d subject business correspondence to those obstacles and vagaries rather than send properly formatted HTML mail to people who have opted in to receive it? Where is the logic there?


We could technically send HTML as an attachment, but why complicate the end users experience by making them open another application when their email client can already handle HTML?

They should have to go through extra steps just because historically email clients were not ‘intended’ to carry HTML?

None of this is intended to disparage the opinions of web designers who disagree with us. It is good and right that dissenting opinions are heard. The Email Standards Project is a pragmatic enterprise though, looking at where we are right now, not where we theoretically could be if things had been done differently in 1998.

It all comes down to a few simple choices


  • Keep complaining about the whole idea of HTML email - result: people keep sending HTML email anyway.
  • Ignore it and pretend it is not happening - result: people keep sending HTML email without the benefit of web designer influence, and with poor rendering.
  • Work at making HTML email support better - result: people keep sending HTML email, but it becomes better designed and hopefully standards support is improved.

There is no option where support for HTML email suddenly disappears and people stop using it.

Support the Email Standards Project!

" OR logged_in_group_id == "1"}

[edit this entry]

Commenting is not available in this weblog entry.