Help improve support for Web Standards in HTML email

I absolutely hate HTML email. I hate receiving it, I hate sending it. And there is no way you can make me actually create an HTML email message that displays well in all email clients.

But many other people want to use HTML in email. Some people even like receiving HTML email. And most email clients are configured by default to display HTML email and use HTML to format messages. So no matter how much I hate HTML email, it isn’t going away. Unfortunately.

I still don’t do HTML email though. As long as support for Web Standards in email clients is as crappy and unpredictable as it currently is, well I’m sorry, but I’m not going back to nested layout tables and spacer GIFs just to create an email. Until the situation improves I’m happy to hand over the job of creating HTML email to somebody else.

So how can we make the situation improve? Probably not by arguing about how much better plain text is. What we need is to somehow make email client vendors improve support for Web Standards (most notably CSS) in their applications. There are different ways of doing that. One is to keep complaining, which probably won’t work. Another way, which I think has at least some chance of actually working, is to help email client vendors.

And that’s why I think Dave Greiner’s article Why we need standards support in HTML email is really important. In the article Dave explains the current problems with standards support in email clients and how it has become worse lately.

He then goes on to mention that he and the others at Campaign Monitor are working on a site that will help email client vendors by looking at the following areas:

  • Establishing a baseline of what standards we need supported in email
  • Document the important changes each of the major email client manufacturers need to make in order to support web and related standards
  • Create a simple acid test that makes it easy to see if an email client supports this baseline

It’s kind of like The Web Standards Project, but for HTML email. Sounds like an excellent idea. I hope this effort pays off and that we can look forward to the much needed improved support for Web Standards in email clients.

Posted on September 11, 2007 in Web Standards

Comments

  1. Ok, I’ll check back 10 years from now :)

  2. It’s kind of like The Web Standards Project, but for HTML email

    HTML email Web Standards Project = HE WaSP? ;)

  3. Hey Roger, I totally agree with you. Dave and the Campaign Monitor team are already doing a great job with all things email related and we really need standards support.

    I really hate it when I have to try my HTML emails in so many clients and it looks so different in all of them.

    I’ve posted about this in Spanish too so that Spanish speaking web developers jump on the boat and support the cause:

    Necesitamos estándares para correo electrónico.

    Regards!

  4. What I really dont get is why some people have such an aversion to html email? - at the end of the day if you dont want it unsubscribe or dont subscriber in the first place. And before anyone says it - we’re talking about legitimate permisson based email here, not spam.

  5. Even being able to tell if a particular email client supported what you were sending them would be a step in the right direction. I could be wrong but didn’t Microsoft take a backwards step re: standards recently? As they’ve decided to use Word’s HTML engine rather than IE(7)’s??? I’m sure I remember reading about that.

  6. HElium, ‘cause it is intended to raise standards higher :).

    With regard to your mail preferences; I like HTML email. What I don’t like is the way most people apply it. There’s a big difference between the two.

    When I send email from web applications, I typically send HTML email with a plaintext fallback. It’s nicer for users. I don’t have to worry about ugly URIs everywhere or broken links because of the idiosyncrasies of trying to fish out URIs from plaintext. But I don’t usually include images or fancy layout. There’s no Comic Sans. My HTML emails are almost identical to the plaintext versions, except they have emphasis like italics or bold, linked text instead of clumsy URIs, the occasional table where warranted, etc.

    Would you complain about emails like the ones I send, or are you like me and prefer HTML to plain text if it’s done properly?

  7. September 12, 2007 by Lance Fisher

    There seems to be a lot of ranting against HTML email recently, not just the implementation, but the idea. It’s the implementation that’s bad, not the idea. It took me some time to get over my aversion for it, but HTML email really does have benefits (yes, I’m one of those weirdos).

    When I get emailed photos from my family, I like being able to view them without opening attachments, and when I get my REI ad in the mail, I like to see pictures of items on sale. Now, bad design can ruin email like it can ruin websites, but don’t blame the medium.

  8. I feel like a bit of an expert in creating HTML email because it was wanted at our work and we couldn’t afford to outsource. Never mind that myself and a colleague or 2 have spent hours and hours and hours developing guidelines and processes. Then if the people who want to create them don’t have HTML skills they have to outsource the creation of them.

    Standards for HTML email would be great, but as the first commenter alluded to, I won’t hold my breath and by then we’ll have probably outsourced.

  9. Me and a couple of our team members are working on a framework for HTML emails that “hopefully” will work in all email clients and push the web standard template design rather than using table based layouts.

    If you want me to email you as we progress just shoot me an email a webmaster (at) xoxo-escorts (dot) com!

    Nadia

  10. September 12, 2007 by Roger Johansson (Author comment)

    Damien:

    What I really dont get is why some people have such an aversion to html email? - at the end of the day if you dont want it unsubscribe or dont subscriber in the first place.

    I don’t know about others, but for me it is because it interferes with my email reading. I have specified which typeface, size, and colour I want to read email in. HTML email with no text alternative (which is most HTML email) disrespects those settings, often making messages harder too read.

    As for unsubscribing, yes that is an option, but sometimes you may need the information in the messages. As an example, Facebook, which has become wildly popular during the last few weeks, tells me only this in the notifications it sends me:

    This message contains a rich-text HTML portion. Consult your mail client’s documentation for infomation on how to view it.

    That is just ignorant and disrespectful. It’s like those browser upgrade messages from 1998.

    Jim:

    Would you complain about emails like the ones I send, or are you like me and prefer HTML to plain text if it’s done properly?

    I would complain less but still prefer plain text since it doesn’t override my text settings.

    Lance:

    When I get emailed photos from my family, I like being able to view them without opening attachments

    Seems like you need a better email client ;-). I’ve been able to do that for years without resorting to HTML.

  11. I would complain less but still prefer plain text since it doesn’t override my text settings.

    A wise man once wrote: “Seems like you need a better email client ;-)”.

    Seriously though, if a mail client supports HTML, it should also support user stylesheets, and if it doesn’t, then this is one of the bugs that a movement like this should address. Thunderbird allows user stylesheets (easily exposed to the end-user with the Stylish extension), and I’m sure it would be relatively easy for KMail to also support them (it just embeds Konqueror, which has excellent support for user stylesheets).

    What exactly do you object to? If somebody chooses which font to use, or the fact that there’s any styling at all? For instance, if this comment was emailed to you for approval (perhaps to avoid comment spam), would you be annoyed at the fact that there are italics faithfully represented in the email rather than being discarded?

  12. thunderbird > view > message body as > plain-text - default, oh yes.

    html emails are utterly pointless. an utter waste of time on both sides. if my boss asked me to code an email i would tell him to stick his business.

    lewis

  13. September 12, 2007 by Kristian Hollund

    I don’t mind getting HTML mail as long as it’s properly made and it’s something I’ve said I want. Which is not many things I have to admit.

    Coincidentally I also work with clients that want this. And I’ve made a small application that lets our users create articles that get nested into an email, sent either in Outlook format or in a simpler table layout. Do I think it’s great? No. Do people want it? Yes. So I’d like to make it possible to make it as good as possible, as it gets worse and worse, and new Outlook will even go back a step.

    Will have to check this out.

  14. Amen to this post Roger. I was recently tasked with developing an ezine and I felt like I was regressing back in time, slicing up the email into images and then putting them together using table cells. It’s an awful experience, and I’m sure glad I don’t work in an email marketing department ;)

  15. Roger said:

    I don’t know about others, but for me it is because it interferes with my email reading. I have specified which typeface, size, and colour I want to read email in. HTML email with no text alternative (which is most HTML email) disrespects those settings, often making messages harder too read.

    And some times plane text is just rubbish.

    The HTML product suggestion emails I receive from amazon (as an example, I usually ignore them) are much better in HTML because I can scan over the page and pick out what I need quickly. In plane text I have to read far more to find the same info.

    By the way, why do the first lines of your articles always break about half way through to the next line? (In FF2 on PC and Mac).

  16. When sending mails to clients I think the ability to add emphasis, bold and use lists adds massively to the understanding of and readability of my emails. I’m talking about otherwise plain text, but with something extra, here.

    I don’t think mail should go any further, but that’s my personal preference. Some people like to send emails using incredimail *shudder*, who am I to disagree with that? (well, disagree-with any further than the “this is spam” button, which I already tick :-) ) You can control the email you send and, for the larger part, the email you recieve.

    For the people that have more “demanding” needs for their e-mail, this is a great initiative!

  17. Email clients are like other browsers. They all act differently to one another and have better strengths and worse weaknesses.

    Until the browsers manage to improve CSS and standards support I can’t see email clients getting remotely close.

  18. My sole job at work is to slice up designs made by print designers for the real estate industry to send in e-blasts.

    The only CSS my boss lets me use is font:. And it has to be inline! AHH!

    I hope this initiative makes an impact soon. I’m tired of purposefully using bad code.

  19. September 12, 2007 by Roger Johansson (Author comment)

    Jim:

    Seriously though, if a mail client supports HTML, it should also support user stylesheets, and if it doesn’t, then this is one of the bugs that a movement like this should address

    I use Apple Mail, and while there is no obvious option to import a user stylesheet is is (or at least has been) possible to use one. Though I don’t see why I should need to fix it at my end. The problem is the sender not bothering to include a plain text version.

    What exactly do you object to? If somebody chooses which font to use, or the fact that there’s any styling at all?

    Others overriding my choice of font face/size/colour and background colour is what causes problems for me.

    Ryan:

    The HTML product suggestion emails I receive from amazon (as an example, I usually ignore them) are much better in HTML because I can scan over the page and pick out what I need quickly.

    Agreed. But I prefer reading such information in my web browser instead of in my email client.

    By the way, why do the first lines of your articles always break about half way through to the next line? (In FF2 on PC and Mac).

    That is probably because you are either using an ad blocker or have JavaScript turned off, or perhaps you are behind a firewall or proxy that filters ads.

    Kilian:

    When sending mails to clients I think the ability to add emphasis, bold and use lists adds massively to the understanding of and readability of my emails. I’m talking about otherwise plain text, but with something extra, here.

    Yes, that is HTML email done right. Leave visual formatting alone and add semantics and structure. I’d be fine with that. I may even prefer it to plain text. Too bad I can’t remember ever getting an HTML email of that kind.

  20. That is probably because you are either using an ad blocker or have JavaScript turned off, or perhaps you are behind a firewall or proxy that filters ads.

    Aaaah thanks, I have the noscript plugin.

  21. September 12, 2007 by Maniquí

    What about reading HTML e-mails in web-based e-mail clients (like GMail or others)?

    My bet is that a web-standard HTML e-mail (that is, less tables, more semantics/estructural elements, with inline/external CSS) will probably look very broken when viewed in a webmail client because (probably) the webmail CSS will be applied also to the our precious web-standard HTML e-mail.

    Of course, this also applies to table-based HTML e-mails (that is, they probably will be affected by the webmail CSS). But certainly, HTML e-mails based on tables, spacer gifs and presentational mark-up are more “solid” and they resists better any CSS applied over them.

    I hope I’m not missing something…

    (I have created an HTML newsletter table-based layout that works pretty fine in Thunderbird, Outlook Express, GMail, Hotmail, and even looks perfect when posted in Craigslist and MySpace)

  22. Maniquí, here’s quite a good resource for webmail and css support.

    @Roger, my name is with one L (common mistake :-) )

  23. September 12, 2007 by Roger Johansson (Author comment)

    Kilian: Oops, sorry about that. *blush* Fixed my previous comment.

  24. My bet is that a web-standard HTML e-mail (that is, less tables, more semantics/estructural elements, with inline/external CSS) will probably look very broken when viewed in a webmail client because (probably) the webmail CSS will be applied also to the our precious web-standard HTML e-mail.

    There’s actually a long-standing in KMail like this. Because the mail headers are displayed in the same frame as the mail content, they decided to be lazy and just put the headers in as HTML. The end result is that anybody sending you mail can do all kinds of dodgy things to your mail header display because CSS from emails apply to the headers too.

    The problem you describe isn’t actually the main issue web applications like GMail have with CSS. That’s easily worked around by putting the HTML email into an inline frame. The real problem is the non-standard extensions that Microsoft added to Internet Explorer - you aren’t just letting CSS through, you’re letting JavaScript through, because Microsoft in their infinite wisdom decided that it would be a good idea to execute JavaScript found in stylesheets.

    The upshot is that if you want to safely include an untrusted stylesheet for rendering, you have to completely parse it, throw out anything you don’t recognise, and generate a new stylesheet with what’s left over. Ick.

  25. It would sound a little bit off topic, but I had my dream once. As I am a big fan on XML and firends, I was dreaming about one interesting standard and it’s update - the MIME mail standard. My vision is to format this very frustrating text based code in one easy reading, parsing and generated format Xmail (email in XML). I even wrote a sample. Oh I wish someday my dream could come true. :)

  26. September 19, 2007 by Stevie D

    Leave visual formatting alone and add semantics and structure. I’d be fine with that. I may even prefer it to plain text. Too bad I can’t remember ever getting an HTML email of that kind.

    Go back 10 years…

    Netscape 4.x had great email setup (*). If you didn’t put any formatting in an email, it sent it as plain text. If you put in some formatting, but didn’t change the default font size/face/colour, it didn’t specify them but left them to the reader’s defaults. It allowed you to use tables and other features of HTML.

    Now almost everybody uses Outlook. The HTML it sends is several grades worse than what Netscape used to. It specifies the font, size and colour (in the worst possible way) and there is no option to not do this.

    Again, this is not a problem with the principle of HTML email. It is a problem with the implementation - the way that Microsoft has shat all over internet standards, compatibility, user experience, everything. If Outlook produced even half as good HTML as Netscape did five years earlier, I’m sure you wouldn’t be in the least bit bothered by it.

    (*) It may be that Mozilla products still do all this. Unfortunately, the market penetration of them is pitifully small, so for most people it’s irrelevant.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.