Email Standards Project — answers to common questions
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!
I’m sold! My blog isn’t widely read, but who cares, I’m posting anyway.
It is certainly true that HTML email is not going away. Sometimes it is appropriate and sometimes not. In most cases email business newsletters benefit from the formatting that HTML/CSS allows for. Why should email be restricted to text? It would be a bit like sending flyers to a printer who only does black and white and only supports courier fonts.
The main thing is to ensure that the sending and receiving applications follow standards for HTML/CSS (and should produce semantic,accessible, usable results). Anything less than that is not taking advantage of what computers are capable of (so is just plain stupid).
I find it incredible that Microsoft messed up so badly with Outlook 2007.
Why is it them again who make our (web developers’) lives so awkward?!
Hey guys,
I think its great what you’re doing for email standards. HTML in email is around and it should be held up to the same level as a regular page on the web.
Is there a spec on what can/should be blocked from email? My concern is for things like JavaScript, iframes, and anything that can execute an action for potential viruses.
-Tim
This project will be a big help. A few of my clients have wanted HTML/CSS formatted emails, and making them work well enough has been a nightmare for me.
Knowing that most people will be able to see the email without clicking that annoying “view in browser” link that most probably ignore will be a relief to me.
Is there a list of recommended email clients one should normally test in?
I am in the process of creating an HTML/CSS email template for a client right now and have my fingers crossed that a majority of his recipients see it ok.
Now if we had standards about this, I would be smiling, not sweating…
Does this include externally linked CSS files or does all CSS have to be in the body of the e-mail? My experience is that it’s been painful to try and write a stylesheet for certain environments because they get stripped out entirely.
When you give your recipients the choice, you will see, that most people will choose to receive html format. With the rise of internet capable mobile devices, the format question might soon be moving in a different direction. Many modern mobile devices can already handle html emails, but you might want to offer special (and more lightweight) html designs for those small screens.
@Shane: The CSS in the body trick has worked quiet well for me. Usually only the head parts are being stripped. The alternative (or do both) are inline styles. It doesn’t make your html pretty and causes more work.
Check out http://www.campaignmonitor.com/css for an overview of what CSS is supported where, including the ‘stylesheet in the head vs separate file’ issue.
Great post Matt! I think it’s sad that we still have to have these arguments.
To me, it seems that many of the HTML dissenters are complaining about commercial email or spam - and they often don’t differentiate between the two. That’s a stance they can take, but it seems that the actual HTML in emails isn’t always the problem. BTW, I also love the complaints about bandwidth, as they stream internet radio and watch YouTube!
I completely agree that emails should be sent in text & HTML, but limiting to text only is like saying you can only have vanilla ice cream—it’s nice some times, but I often want to experience all the flavors.
If you’re going to apply standards to newsletters, you ought to first apply them to your site. The proliferation of identical, non-contextual links on the page (Read more, Full report) should be addressed right away.
As far as newsletters goes, I agree that HTML is a valuable and popular option...but some of your conclusions are very one-sided. The HTML attachment point, for example, neglects to mention that the user could quite simply click a link to an HTML web page. No need to drag and drop into a browser. Also, there are many benefits to having your newsletters hosted on a web site - indexed by search, can be viewed in browser as opposed to email client (great for users of assistive techs with custom style options), stats reporting through usual site reporting tool (e.g. Google Analytics), easier to provide multilingual option, etc...etc…
I think it’s worth focussing on the real benefits of HTML newsletters - i.e. that they arrive with graphics and formatting, that they have ‘inbox impact’, that they are often forwarded (check out the thousands of jokey HTML emails out there), that they facilitate genuine interaction, that they can offer click tracking direct from inbox… There’s loads of real benefits, let’s try to focus on them and not get distracted by arguing that HTML offers all things to all men.
Why aren’t any Linux-based email systems being tested? While Thunderbird is fairly well used on Linux, I use Evolution (I appreciate it’s calendar/to-do list capabilities) and CampaignMonitor’s emails do not render correctly (close, though). How can the Linux community help? Please don’t ignore this growing section of users!
@Andy - You are right that Linux is a growing section of users, but in reality they are still a miniscule portion of email users.
Also, Linux email clients typically are more standards compliant already, and Linux users more likely to want plain text in any case.
So right now we are concentrating on the big targets, but we’ll certainly look at ways of broadening the project as it goes on. Thanks for your feedback.
@James
We take your point about the links, although they are contextualised to a degree by where they appear - a ‘full report’ link is not isolated, it is proximate to a heading with the email clients name in it. So that does help, but we could do better in some cases certainly.
Regarding HTML as attachments, if you are able to click on the link to the page it is not really plain text anymore is it? It’s some hybrid form, which is another argument.
You are also correct that web based newsletters have other benefits, but they are for the designers and not the end user, who just wants to read the content.
There’s loads of real benefits, let’s try to focus on them and not get distracted by arguing that HTML offers all things to all men.
We are certainly not saying HTML is all things for all men - just that since people are using HTML email, it should be using existing rendering standards.
How can I make a blog? What CMS can you advise to me?
This is fantastic. As someone who is required to build 2 - 3 html emails a week as part of my job I can’t support this project anymore.
What about accessibility?
I have seen no info about best practice to implement HTML email using EM instead of PX for font sizes.
Especially considering that gmail “new version” renders EM font sizes at some arbitrary tiny size compared to the rest of the world.
Any advice here - please!!?
regarding my above comment: i hope i didn’t sound rude/dumb
- what i am looking for is…
for your “acid test” you show font size as em/px --> ? how do you give both?
is the code for the “acid test” email available, so that designers can access it and learn from that - is it available? i may have missed it.
i guess i’m a bit on the frustrated side after many many hours of testing and very little info to gather.
I really appreciate what you are doing here, and i support it fully!
thanks for letting me rant, and all the best.
I think ESP is certainly fighting a good cause. Just my two cents worth on a couple of the issues…
HTML email is here to stay whether people want to accept that fact or not. Lets face it we like “pretty”, everyone likes “pretty” and the more people get accustomed to the look o HTML emails the less they are going to want to go back to text emails.
Sending HTML email as attachments will never fly. It’s another unnecessary step for the recipient and we are lazy people! We do not like extra steps.
“we don’t have the right to tell them all what they should and should not like.”
How true this is. Nobody should be trying to dictate what email type the general public should use. And I do agree with the above post that the majority of the general public are going to prefer HTML as it’s simply nicer to look at.
I do SEO full time and most of my clients communicate with my by email. My biggest problem with my company email is that I keep missing email or get them a few days later. I heard great things about Gmail, but being free, I am not sure it is a good choice. any opinions on this?
Thanks!
Manny.
It would be fantastic not to be limited to textmails but also could choose to send html-emails. This would be something very special and we could design our unique mails...it also would open up another internet-market. Great Project!
You folks are definitely setting a trend here with HTML standards! Thanks for paving the way....
Excellent job everyone. HTML emails are the overlooked market.
Thanks for all of your research on email standards.
Hi Guys, once again i just want to say that this is really awesome what you are trying to do and prove by working have on it instep to make those email standards public and used by the huge companies out there, thanks again and keep it us guys.
I also want to say thank you for your great work and all the information you are giving us by spending your precious time in informing people like us. Your research on email standards is something I really enjoy and always looking forward to more information.
Thank you,
Joe Pelligra
The only one problem with html messages - I receive 90% of the important messages in a plaint text, and half of spam or advertising in html, so the first reaction on colorful html message is negative.