This is a post I’ve been meaning to write for a long time now. I’ve been delaying it purely because I wanted it to be perfect. I wanted to write with Zeldman-like virtue on why email, just like the web, needs to pay attention to web standards. Sadly, in the time between the idea for this post and actually getting it published, web standards support in email has gone seriously downhill. I can’t delay it any longer.

My role at Campaign Monitor has given me a great opportunity over the years to research and speak to other designers at length about the standards issue. Each time the topic comes up the result is always the same – getting an email to display consistently in all of the popular email clients is by far the most frustrating part of the job. It’s a painful and always moving target that’s getting harder instead of easier. There’s really no justification for it and it’s about time something was done.

Accepting the reality of email today

Let me preface this by saying I completely respect everyone’s choice for the email format they prefer to send and receive. I also understand that it probably wasn’t the original purpose of email to go beyond one-to-one plain text messaging. I really do. This is one of the biggest reasons we encourage everyone to include a plain text alternative whenever they send a HTML email.

But we need to be realists. Every popular email client supports HTML email and most use that format out of the box. Out of the box means it’s the format of choice for anyone outside of the design and early adopter community and there’s no indication that’s changing any time soon. No amount of angry comments on Slashdot singing the praises of Pine are going to suddenly force email client developers to drop HTML support. It’s just not going to happen.

So, it’s not going anywhere and it’s broken. If we can all get past this point together, it’s obvious that the best path forward is to work with desktop and web-based email client manufacturers to improve how HTML emails are rendered, not argue amongst ourselves about personal preference.

What’s wrong with the current picture?

Today there are at least 10 popular email clients out there, each offering different levels of standards support ranging from perfect to virtually non-existent. I often hear comparisons between the current state of standards in email and the web circa 2000. While there certainly are some similarities, there are also some big differences.

The web standards movement faced not only poor browser support, but also an uneducated design community. They had browser makers and designers to convince. Today we’re lucky enough to stand on the shoulders of these giants in a world where web standards have well and truly been embraced by browser developers and the design community alike. People want to build HTML emails using the same approach they build for the web.

Another big differentiator is the fact that there were 2 or 3 browsers to consider back then and we knew exactly which web browsers were popular, making it much easier to know where to focus our energies. There is almost no data like this for the email world. Are more of my subscribers using Thunderbird or Apple Mail? It’s almost impossible to know. So, we’ve got 3 to 4 times more variations to cater for and we don’t even know which ones we should be targeting.

Because of this huge variation in standards support, email designers have been forced into a corner. There have certainly been valid attempts at encouraging the use of web standards in email, of which I’m proud to say we’ve played a part. The W3C has even jumped on board in realizing something needs to be done here. With the recent and unfortunate news from Microsoft however, it’s been getting harder and harder to justify this approach.

What we’re now left with is building for the common denominator. This means bandwidth hogging, image heavy emails with nested tables and font tags. Yes, I said font tags. I see hundreds of these designs being sent every day purely because it’s the only way to achieve consistent rendering across the board. Type in the URL of those creating these designs however and you’ll often find a beautifully coded standards compliant site. Email design truly is stuck in the dark ages.

Revisiting the benefits of web standards

Many of you are already well aware of the positives web standards offer, but I’ll focus on those I think are particularly relevant to email.

  1. It removes the guess work from email design – This is an instant win for designers and everyday email users alike. If all email client developers aimed for something close to web standards, you can design an email knowing it will work for all your subscribers. Stop and think for a second how awesome that would be. Your subscribers will win by no longer receiving garbled, hard to read newsletters because their email client doesn’t support standards.
  2. Faster loading and reduced bandwidth consumption – Well coded, standards compliant markup that separates content from presentation is generally much more compact than nested table and spacer-image based markup. Further to this, many designers have given up on rendering issues altogether and send purely image-based emails. This adds significantly to the file size and results in a poor experience for their subscribers because of image blocking.
  3. Make your email accessible to all – Using standards does not automatically mean your email will be readable to people with disabilities, but it’s certainly a great start. By separating content from presentation you’re making it much easier for everyone to access your email.

Further to these intrinsic benefits of web standards, there’s another significant win that would follow. Using tables for layout is a dying art in the web design community. Many designers who started web design in the last few years have never even coded a table based layout, which is a good thing. The current email environment means a designer not familiar with the table based approach will need to learn a completely different way of creating a page if they want to send HTML emails.

We’re fast approaching a fork in the road where email design will become a niche, expensive service that fewer designers can provide. Sure, a few designers win by being able to charge more for their work, but everyone else loses.

Where to from here?

This much is clear – arguing about HTML vs plain text or complaining about standards support in email isn’t going to get us anywhere. It’s time to get off our butts and actually help email client manufacturers to introduce better standards support.

I also think it’s important to realize that these manufacturers don’t have a problem with web standards. Supporting standards might not always be the easiest option, in fact for web-based providers I’m sure it’s quite the opposite. It’s our job to demonstrate why they are important and then make them as easy as possible to embrace.

We’ve been hard at work on this for the last few weeks, focusing on the following areas:

  1. Establishing a baseline of what standards we need supported in email – We certainly don’t expect perfect standards support across the board initially, but there are a number of key properties that we can encourage manufacturers to support sooner rather than later.
  2. Document the important changes each of the major email client manufacturers need to make in order to support web and related standards – Once we’ve established the baseline, we can put together a basic wish list of the changes each manufacturer will need to make to meet this target and then work with them in any capacity possible to help make this happen.
  3. Create a simple acid test that makes it easy to see if an email client supports this baseline – Much like WaSP’s Acid2 test, we should make it easy to see if these important standards are being supported by creating a simple test page that can be viewed in that email client to confirm at a glance if the baseline is being met.

We plan on bringing this all together in a dedicated site launching soon. Obviously the more of us that can get behind this the easier the job will be. Even the king of web standards, Jeffrey Zeldman agrees (emphasis his):

Learn how HTML mail works (or doesn’t) across as many platforms as possible, and work with the manufacturers to improve support for web standards. This is not my job. I did my job where web standards are concerned (you’re welcome!), and turned over The Web Standards Project to a new generation of leadership. And as I never send HTML formatted mails, not only is it not my job, I wouldn’t even be qualified to do it. But standardistas who are compelled by their clients to create HTML mails (or who choose to do so) are gently urged to do their part in diminishing wasted bandwidth and enhancing semantics.

We’ll be posting more about this initiative soon, including how you can help make a difference. Jeffrey’s right, it’s not his job – this one’s up to us.

Update: You can start helping right now. Check out the initial list of baseline standards that should be supported and add your own thoughts.

  • Damien Buckley

    I am so glad to read this article – and glad its come from you. I’m sick & tired of hearing the knockers complaining about html email – if you dont want it, unsubscribe. I’m in the class of designer who didnt learn to use tables (thank God) and have read, studied and worked damn hard to design and build clean, semantic, standards compliant websites. We’ve been working with CM from almost as early as we started designing websites and I started out building emails in the exact same way I do websites.

    What’s frustrating is that lately, with the news from Microsoft etc, I’ve gradually started going backwards. Rather than starting with clean sheet html and working through pure CSS positioning and styling, using image replacement techniques to keep everything accessible, these days I generally start with the free Mailbuild templates (and just before anyone gets upset – there’s nothing wrong with them) and customisig to suit.

    There’s really no sense whatsoever in what Microsoft have done reverting back to the Word rendering engine but to be fair, when did they ever do anything for web designers and the standards movement? I think its testament to the fact that the left hand doesnt know what the right hand is doing that the IE7 team could do such a great job in getting the world’s most widely used browser up to date – and then another team completely ignore it and roll back to 1980 on the email front????? Does anyone else find this completely bizarre?

    In addition to this article I’ve also read elsewhere that there are some industry big-hitters working hard to silence and run the standards people out of town in the HTML5 working groups also and so it seems that its not only html email under attack but we could be in for a whole new era of non-standards stupidity in browser development to further the big boy’s causes.

    I was extremely disappointed with Zeldman’s post that set some of this issue on fire in the first place though relieved to see a semi-retraction follow it. That said, he’s done a lot already and as he rightly points out, we can’t wait around for him to take up a fight based on something he’s not really involved in.

    I’m completely behind DG on this one and agree that this is a fight we have to take up ourselves. Sign me up.

  • Dave Greiner

    Thanks for the words of support Damien, that’s much appreciated. I can see that the issue has slowly worn you down too. I also think that moving forward it’s important not to point fingers in any specific direction for the current standards mess.

    As I mentioned, there’s no doubt that implementing standards support isn’t easy, and there are always internal reasons why a particular product might be released the way it is. We can’t change that now, but we can work with them to forge a more positive direction for the future.

    Consider yourself signed up.

  • Chris Harrison

    Count me in.

  • Ricky Cox

    I thought you’d enjoy this

    https://signalvnoise.com/posts/481-screens-around-town-xbox-sharp-and-r-mail

    QUOTE

    “This amused me to no end – support for modern (X)HTML/CSS in Microsoft’s Outlook 2007 is so bad, they have to add a disclaimer for themselves. I saw this at the top of my Xbox Live newsletter.”

  • Steve

    ((((((STANDING OVATION)))))))

    I’m in with all levels of support that I or my company can offer to you and this effort.

  • Derek

    I completely agree!

    The Web Standards Project need to set up an email task force ASAP, if they haven’t already done so.

  • James Oppenheim

    I think this is a fantastic idea, rather than bitching help provide a solution that is so very needed. Excellent article and I can’t wait to see what you guys are up to next. Well done on hopefully the being of the end to the current HTML email debacle.

  • Richie

    @Ricky Cox:

    It’s worse than you know: Outlook 2007 changed to Word for HTML layout and we all know what a superb job that does with/to HTML.

  • Gregg Oldring

    David, you know I’m on board. I’m so glad you wrote this post.

    The key to success is to start a dialogue with those who develop email clients and learn why they’ve chosen to stray away from standards. I suspect that most of the rationale is tied up in old anti-phishing measures that are seldom used today but it is important that we listen to their needs.

    I’ll be watching for your next post. I’m intrigued at what you’ll propose. I say we do a road trip and just show up on people’s doorsteps. Cupertino, Sunnyvale, Mountain View, Redmond. It could be epic.

  • Daniel

    Its about time!

    I totally agree with every posted here. Is it just me or is there reasoning behind why the email clients couldn’t use the web standards that are already place?

  • Chris Blown

    Its just so wrong that in this day and age that we even have to write about this sort of thing.

    Yes IE7 is better, but M$ would have saved themselves a bunch of time by simply integrating gecko or webkit into IE7 ( at as a rendering option ) Ok so they’d cop some flack for a while but give it a month or so and everyone would forget about it. Same goes for any email program on any OS, why they don’t use open source html / css rendering engines is beyond me..

    Is not just M$ either, Evolution ( a linux based mail client ) suffers from dismal support for modern html emails, as it uses some old gnome library for rendering.

    The mind boggles…

  • Light & Dark

    Hallelujah.

    Definitely preaching to the choir here, but I’m in for what little I can contribute to the process. even if it’s just following the work and trying to get the word out.

    I do think you’ve hit on a significant reason the mess is as bad as it is – html email has been the red-headed stepchild of the web ever since it started. Nobody’s ever actually made a business case for why the providers should improve, so they’ve just heard a bunch of whining that’s easy to ignore.

    I’ll be watching developments with great interest.

    Paul

  • Seth Aldridge

    I would be down for helping define email standards. This is something that will a little work and dedication could have a huge impact on the global email market.

    Even just for presentation emails that are internal, giving companies the option to “brand” their email with very basic CSS code would be amazing.

    Sign me up!!!

  • Hamish Stevenson

    Of course I agree with everything you’ve written Dave and all comments above. Simply increasing the volume of whining will do little. Constructive solutions like “Establishing a baseline of what standards we need supported in email” is not only constructive and forward-thinking, it raises us above the plethora of annoying, whining standards-based designers who do nothing but complain.

    The only ‘other’ comment I’d make is, I think we need to be careful not to point all criticism at Microsoft (obviously they’re easy to get upset at, but I see many people, by default, blaming Microsoft for all their life’s woes without much thought put into the criticism). While Outlook 07 is disappointing, I’ve seen all the arguments and reasoning behind why they went that way (Word for HTML layout etc) and some of it (eek) kind of makes sense. As a designer/coder, to be honest, getting around Outlook 07 deficiencies is the least of my problems. The reality is, for many of my clients, the growing number of subscribers on their lists are on gmail NOT Outlook. There are obviously so many reasons why HTML emails struggle within a webmail environment, but as far as I see it, and given the increasing number of young people signing up with gmail/hotmail etc, this is no longer a plain-default debate about how mutant Microsoft development roadmaps are in their apps. Google, as far as we’re concerned, is my company’s biggest headache right now with email design! Email clients need a constructive, objective and intelligent roadmap across the board! Let’s not turn this into yet another excuse to have a Microsoft-bashing session by default (sheesh… did I just write that?).

    Without even questioning, we’d be on board in any way we can help Dave. As always, loving your work mate.

  • mind

    pine? nice straw man, very easy to knock down. the standard client these days is mutt

    but no worries, i don’t particularly want to read any email that is part of a ‘campaign’.

  • Phelps

    There is another issue — a lot of us are getting our email on less and less capable devices. I prefer to be able to handle my mail on my iPhone (and Blackberry before that.) Any standards that we come up with have to take into account that a lot of email will be read on mobile devices that are trying to eke every bit of work out of their battery that they can. I expect mobile devices to continue to focus on conservation rather than power (since a processor advance is more valuable in extended battery life than raw horsepower.)

    Plain text and even formatted text is fine on a mobile device. Complex cascading layouts are too slow and too detailed.

  • Mathew Patterson

    That’s a fair point Phelps, and people who are sending to audiences likely to be reading on mobile devices should keep it in mind.

    On the other hand, people are also viewing more and more full on web pages through mobile devices (like iPhones), so the rendering of html in email is not a processing power problem on those devices.

  • Dave Greiner

    Great comment from the mobile perspective Phelps. Further to Mat’s point, I’d also suggest that the more we move to a standards based approach and properly separate content from presentation, the easier it will be for mobile devices to “dumb the content down” and display an accurate rich text version as opposed to a mess of tables and spacer gifs.

  • Nick

    @ Richie

    “It’s worse than you know: Outlook 2007 changed to Word for HTML layout and we all know what a superb job that does with/to HTML.”

    I’d understood that it had changed to using the *Office* rendering engine (which Word also uses). Is that not so?

    It seems to me that there could be, and probably are, valid reasons for doing that. Has anyone asked Microsoft why they did it?

    One might be security. Email clients’ using Internet Explorer has proved something of a security problem in the past–although now that Microsoft’s run the content, by default, in the Restricted Zone, it’s less of problem, and the most important infection vector these days seems to be the web not email.

    I posted not to pour cold water on you guys, like the angry Pine user above, but just to make the point that there may be other considerations in that move and those considerations may have their own weight. To be sure HTML standards are important, but if there’s one thing that’s more important it’s security. Microsoft’s past practices have left us in this position:

    http://rixstep.com/1/1/20070902,00.shtml

    If they’re finally taking some steps, and if not rendering the HTML in the browser is part of that, then that’s no bad thing.

  • webtuga

    Html and css please.

  • Dave Greiner

    Nick, thanks for your comments about the security perspective. I completely agree that there are other priorities to balance and rendering is only one issue email client manufacturers need to consider.

    Of course, it can sometimes be hard to see how support for CSS properties like float or background make an email client any less secure ;) Having said that, there are some properties which we understand can’t be supported in web-based email clients like position and negative margins.

    These sorts of considerations will all be taken into account when finalizing the baseline standards that need to be supported.

  • kL

    I think proper CSS support is even more important for e-mail – the *cascade* part especially.

    I don’t want your tiny fancy fonts!

    So I want be able to override fonts, colors and other stuff that I find annoying, without it backfiring in more complex e-mails. That’s the hard part…

    Oh, and support for more advanced web standards also allows for more advanced spam cloaking techniques. That’s bad :/

  • Dave Greiner

    Oh, and support for more advanced web standards also allows for more advanced spam cloaking techniques. That’s bad :/

    I’m not sure what you mean by spam cloaking techniques. I’m guessing you’re referring to phishing, but am unsure how support for web standards could in any way have an impact on spam/phishing emails. Care to share any examples to back this claim up?

    I occasionally hear people fall back on the security question to justify lack of standards support in email clients, but have never come across any evidence to back this argument up. We’re not calling for support for JavaScript or iframes here, just the ability to render basic CSS properties.

  • Mathew Patterson

    Not to mention that most spam I see doesn’t seem to bother about cloaking itself at all!!

  • Bill

    Great post, David.

    When it comes down to it, I’m one of those in the “compelled by their clients” camp – and just budgeting a project involving creation of an HTML email can be extremely difficult.

    The amount of testing alone that is required often makes no sense to the client, considering it’s really just a web page – as they like to point out – and as you really can’t refute. And as you point out, it’s often difficult to even find resources gifted with the knowledge of old HTML formatting and layout techniques.

  • Mike Johnson

    I completely agree that HTML email adds overhead,increases file size, time to download and added internet traffic. Plain text email is simpler, faster to download, and reduces traffic load on email servers.

    My largest annoyance to HTML coded email, is that I am visually impaired (blind) and use a screen reader. HTML emails are VERY distressing, difficult to navigate, and bury the text of the email in large amounts of HTML code gibberish, and generally cause no end of frustration for a screen reader user.

    I can “read” (hear) a HTML email, but it not unlike being in the middle of a “cat amongst the canaries” chaos scenario.

    Simply put, a plain text email is heaven sent, pure bliss for those using a screen reader.

    I am not one of those ADA (American Disabilties Act) extremists that insist the world change for my convenience. I would like some consideration / empathy for those in my predicament.

    But really, just using a PLAIN TEXT fomat or at least including one, would be greatly appreciated if adopted by email developers. The KISS (Keep It Simple Stupid) is not a bad idea.

  • motherduce

    I agree that if an email MUST be HTML, then it also MUST be standards compliant and accessible, and also include a plain text version. However, I’m also of the opinion that HTML emails are highly overrated depending on your audience.

  • Gregg Oldring

    Mike Johnson (and anyone using a screen reader to read your email), I’m interested in knowing more about screen readers and email clients. I set up a number of css layout email newsletters for healthcare agencies but I never had a way to test them. The content of the newsletters were separated from the presentation but I had no way of testing whether or not it really helped. What email clients and screen readers are common?

    On a sad note, I had to redesign these newsletters as sighted people adopted Outlook 2007 and could no longer read them…

  • Jim

    Mike Johnson,

    The MIME standard allows both an HTML version and a plain-text version to be sent in the same email. If you are having problems with HTML, it’s either because the sender doesn’t avail themselves of this option, or because your mail client is set up to prefer HTML to plain-text.

    I understand the problems you are having with HTML email, but *properly-authored* HTML is actually better for aural software than plain-text. Having HTML and CSS rendered properly by mail clients makes it easier for developers to send properly authored HTML rather than the crud that is usually sent today.

  • web standards

    This is a very interesting article. Not many people think very hard about this issue. Personally, I like to get my email in HTML just so it’s formatted the way the creator wanted it to be, rather than changed to plain text.

  • Mike Johnson

    Response to some comments regarding accessibility:

    I am no expert on these issues, just a screen reader user.

    In truth, I do have sympathy for developers trying to provide accessibility (in this case emails, screen readers for the blind & HTML issues). It really is an issue of many versions of different OS, email client applications, and different screen reader application implementations. The many permutations and combinations may (and probably do) introduce variable results, bugs, and performance use issues.

    I know sighted people like colors, font manipulation and text appearance etc and perhaps HTML is just an easy way to implement this.

    I made an emotional response in my off the cuff reply. I apologize for that. It is my personal response (I use a screen reader) that I dislike encountering HTML email as it adds a layer of complexity in most cases that I encounter it.

    Yes, some email clients handle it better (more accessible) in composing email content and in receiving it (displaying it) as well. But I still get emails that are HTML chaos. Yes, it would be great if ALL HTML coded emails included a plain text content as well, but obviously some don’t judging from my experience.

    As I said, I am not an ADA extremist expecting the world to cater to me & my convenience. But strictly from an moral & ethical viewpoint, if features can be included to make a product more accessible to those who need accessibilty, it would be greatly appreciated.

    For what it is worth, I am on several email list servers for support groups for the visually impaired, blind, & eye diseases and majority of members prefer PLAIN TEXT over HTML content for emails. Plain text is in general,much easier and consistent for us to utilize.

    Thanks to all for discussing this one aspect of HTML standards considerations.

  • freddy

    I agree with you 100% in principle, but Microsoft needs to make a significant shift in evolving their email client in order to make this a reality. Based on their track record, I don’t see it happening anytime soon. HTML email would be better if it supported web standards, but I prefer using RSS feeds anyway.

  • Will

    Where do I sign up?

    Seriously though, what can us designers/developers do to help the situation?

  • Jason Grunstra

    Thank you. Just… thank you.

  • Tim

    This is an interesting topic for me. I generally take the plunge to develop emails using no tables, which is an interesting task in itself. Can we please add margin support to Hotmail? :)

    Anyway, I think there really needs to be a community or task force developed to advocate for standards in email. Being that the Web Standards Project hasn’t created a task force yet, we should create our own. Thanks for bringing this up, Dave.

    And sure, you can play the Microsoft card – that they hold all the power – but if there’s enough call for a shift they’re bound to shift. IE7 was a shift (although perhaps not far enough in the right direction!)

  • Radzster

    @Jim,
    I second you on that. The option to send out both versions of an email campaign, plain text and html, are available to every sender, in every major email campaign managment application. It’s another one of those “best practices” issues everyone knows they should do… but eeh… that would add another 2 minutes to the ticker.
    Such a shame… The fact that most recipients are not visually impaired or use a mobile device to view your emails, and are more responsive to “pretty pictures and colours”, does not in any way justify making it more difficult for those who are. It’s bad marketing and results in disengagement and lost opportunities.

    From the end of someone who has some experience with designing email templates and websites… Microsoft’s decision to ignore the design and delivery developments of email marketing in the past years, means more work, more overheads and a lot more frustration, discontent and aversion towards their brand.

    They simply don’t get it, do they… Larger companies and corporations have their own in-house marketing teams to develop these email campaigns. Frustrating their efforts and increasing their costs by “winding things back a bit” in order to try and control the market, is more likely to result in “let’s skip that latest MS upgrade, shall we”. The decision makers at Microsoft still have their heads stuck in the nineties, it seems. Microsoft has a lot more to gain from embracing web standards, than from trying to force their out-dated approach to product development down the webdev communities throat… If they want some kudos, support and respect for their brand, they better start listening.

    Instead of insisting on causing so much frustration and commotion… Go with the flow… Go web standards!

  • Harvey A. Ramer

    Thanks for this article. I’ve struggled with design for email and have concluded that using CSS for structure is nearly impossible with HTML email design. It feels as though we’re about 10 years behind in email design techniques. Tables and images slicing -> Yay!

  • _rs

    Nothing can be said that hasn’t already been said. I’m sick of tables, frankly, I’m also sick of inline styles. Any help from the many different email clients to get them to work better together would be nice.

    Go web standards, go!

  • agustufus

    I thought the reason to switch outlooks rendering engine was to ensure html created in word looks the same in outlook. Email will always have a text and html version so screen readers need not worry (I would complain to the people sending the email if a text version was not sent), but it would be so nice if I knew some email clients didn’t strip the head out of the email so I could get away from in-line styes. Word to your mother.

  • Chad Cross

    Well put. I will help in any way that I can. These email programs make us all look bad because our clients don’t understand the issues. So I am sure they immediately think it is our lack of skill or knowledge.

  • Kezia Payne

    There is a definte need for standards. I recently had to abandon CSS to design an email newsletter specifically for Outlook. And for me reverting back to tables and inline was absolutely a painful process and went against my core.

    Microsoft has always been against playing ball when it comes to standards and all these email clients applications need to have some sort of SOP so that we designers and developers can produce the best work for our clients – the end user.

  • Steve

    I totally agree and also further Hamish’s comments about gmail etc. As if it’s not tricky enough having to tweak website css (and sometimes x/html) for three ‘major’ browsers these days (IEs 6 + 7, Firefox) when designing for email we’re looking at a dozen or more possible desktop and web-based platforms.

    How nice would it be when creating a visual identity for clients to be able to reuse most of the website html and css already written instead of having to start from scratch with tables and inline styles? As Chad points out it does make us look unprofessional when painstakingly designed email templates display oddly for clients and/or their recipients. In some cases I think I’ve spent nearly as much time tweaking simple email signatures or templates for clients as building their entire sites…

  • Dave

    Unfortunately, as has been said numerous times, Microsoft doesn’t seem to have any desire to conform to web standards. Or any standard for that matter. Because once they do, it levels the playing field. Heck, the only reason IE7 fixed the box model was because Firefox was actually catching on and web developers were practically blowing up the IE blog telling them to fix the piece of garbage that was IE6. Having a campaign for standards is a very good start because it raises awareness, but until MS is taken down a notch I don’t see them following. They just don’t have to….

  • Jim

    > Heck, the only reason IE7 fixed the box model was because Firefox was actually catching on

    Actually, Microsoft fixed the box model in Internet Explorer 6, released six years ago, before Firefox existed. If you are having trouble with the box model in Internet Explorer 6 and not 7, then it’s because you are including an XML prolog, which is against Appendix C of the XHTML 1.0 specification, and kicks Internet Explorer 6 into quirks mode, where it intentionally gets things wrong for backwards-compatibility.

  • Radzster

    @Jim

    Hi,
    Are you sure about the XML prolog (DTD)? I always thought they were mandatory from a W3C perspective, in order to be able to validate your document? Would the IE’s Quirks Mode switch (to ensure IE’s backwards compatibility) really have been necessary, if MS had cooperated with the W3C, and developed their popular browser according to the web standards guidelines to begin with? And I thought XHTML 1.0 Transitional was meant to deal with most of the HTML 4 backwards compatibility issues?
    Hey, I’m absolutely no expert here… So correct me if I’m wrong.

  • Jim

    > Are you sure about the XML prolog (DTD)?

    The DTD and the XML prolog are two entirely different things. The DTD is mandatory in XHTML 1, the XML prolog is not.

    > Would the IE’s Quirks Mode switch (to ensure IE’s backwards compatibility) really have been necessary, if MS had cooperated with the W3C, and developed their popular browser according to the web standards guidelines to begin with?

    I disagree with the mechanism they used, but some kind of backwards-compatibility would still have been necessary. There are various things that have traditionally worked a certain way before things like the CSS specification existed, that aren’t compatible with the W3C’s specifications. For instance, vertical alignment of images in tables. Remember, Internet Explorer is only a year younger than the W3C and existed before CSS and HTML 4.

    > And I thought XHTML 1.0 Transitional was meant to deal with most of the HTML 4 backwards compatibility issues?

    XHTML 1 Transitional isn’t related to moving from HTML to XHTML. XHTML 1 Transitional exists basically because XHTML 1.0 is an almost identical copy of HTML 4, except built with XML rather than SGML, and HTML 4 includes HTML 4 Transitional. HTML 4 Transitional exists to provide an upgrade path for people using legacy HTML 3.2 and non-standard cruft. There was arguably no need for XHTML 1 Transitional. The only part of XHTML 1 that is related to compatibility with HTML 4 is Appendix C.

  • Yair

    It is unfortunate that no one even thinks of the needs of people who happen to have a right-to-left language. Any complex e-mail with mixed languages becomes impossible without HTML (pasting Unicode directional formatting codes into email is not a solution – many clients do not support this, and it’s a nightmare to edit).

  • mauricio

    dfg

  • kidd redd

    Your signup form for the new site is not working. Safari 2.0.4, MBP Core Duo 2ghz.

  • devnull

    Where does it say that emails were designed to use HTML
    http://www.lemis.com/email/email-rfc.html

    No email client needs to support HTML. There’s no design that says they need to. If browsers and rendering engines can’t get web pages to render correctly why even bother with email.

    New Campaign: Use plain text only
    Why?: It supports the most clients around. Everyone can render it(fonts, encodings and such being the only problem remaining).

  • Heather

    I applaud your efforts and cannot tell you how excited I am that someone has picked up the torch. It’s bewildering, if not down right infuriating, that email has lagged behind the times for so long.

    The Email Experience Council (https://emailexperience.org/…, a fairly recently formed group of email marketing professionals, has had great success in their efforts to standardize the marketing and design aspects of email. While your efforts are more technical in nature, we all know how inextricably tied the various facets of any interactive project are and, to that end, I’m sure they would be very interested in helping you further your cause. I would SERIOUSLY consider contacting them – Jeanniey Mullen specifically (jeanniey at emailexperience dot org).

    Thank you, thank you, thank you, again for taking this on!

  • iamitcorp

    I hate to think I’m in the dark ages when it comes to email design (being only 34 year old) but apparently so after reading some of these postings! With a background as a self taught graphic artist turned online marketer, not a web developer, HTML email opened the door to do something more creative with the medium of email other than just text. I got into this around 2002 (I think), working with the only tools I trusted for doing print and web page design (Adobe & Macromedia). As a reseller of these technologies, I remember when CSS and absolute positioning were first introduced but my experience with both proved unstable. So I just stuck with the lowest common denominators (basic HTML, tables, and images) which has seemed to work and has been reinforced over the years by documentation provided by almost every ESP I’ve worked with. Apparently either I’m missing something or these new techniques have yet to win me over. I appreciate Mathew characterizing this as a dieing art because that’s really is how I feel about it. I’ll admit, I’m intimidated by new web technologies that seem to only benefit programmers and as a result increase the learning curve for marketers or designers to participate. All the jargon thrown around like, “well coded, clean sheet html, standards compliant markup, pure CSS positioning” ect. For me, it just adds to the confusion of how to simply and efficiently design and deliver successful email campaigns for my clients.

  • Anna

    Seems like standards were a good idea way back in ye olde early sendmail times, and then HTML email came out, then voila, nefarious people did bad things with it. But supporting a smaller framework HTML with no exterior JS link support or iFrames, but standardized object model… it seems just to clear, simple, and practical, dare I say obvious, to NOT be done. Thanks for starting the ball rolling- and I’ll definitely blog about it Wednesday (australia time)!

  • Douglas Karr

    I would propose a 4th area, alternative support via a browser. Currently, most ESP’s provide an online HTML version of the email. If there were support for an internal tag, ie. , software application providers could simply alert the user:

    “This email has functionality or features not supported by [ie. Outlook]. If you would like to view the online version of the email, please click here to open the message in your default browser”.

  • Alex

    Thx for the article. I totally agree with the html-standards for e-mail.
    We need to have these e-mail standards, like currently standards for websites.

  • See Message

    This page is not Valid XHTML 1.0 Strict!
    Result: Failed validation, 31 Errors

  • Bill

    With web and email standards in constant motion, Flash moving more towards object-oriented programming, I think it’s time to interview for that catamaran second mate job in the Virgin Islands. ; )

  • med08

    pine? nice straw man, very easy to knock down. the standard client these days is mutt

  • parkiety

    I standards also use and command this to all there is the future

  • Ashley

    Thought provoking stuff.
    The market should set the standard in the long run.
    Standards can also lead to monopolisation, Good or bad?
    Blue Dot Internet Advertising

  • ÅŸirketrehber

    Your signup form for the new site is not working. Safari 2.0.4, MBP Core Duo 2ghz.

  • Tom

    Thanks for the words of support Damien, that’s much appreciated. I can see that the issue has slowly worn you down too. I also think that moving forward it’s important not to point fingers in any specific direction for the current standards mess.

  • Jonathan D

    I like the idea of a HTML e-mail web standards movement, but I can’t help but think we’re doing their job for them. They are supposed to be elite developers and we have to spoon-feed them this?

    BTW I am one of those developers that use tags, but its on account of Gmail, which I would consider the second-worst common renderer (though not nearly as bad as Outlook 2k7.

    It’s just a mess.

  • Alan Cyment

    I reckon non-standard HTML rendering lurks also in other places, such as Pronto devices, OLPC machines, cellphones, add-hoc kiosks…you name it!

  • Rules

    I completely agree! I think this is a fantastic idea. The Web Standards Project need to set up an email task force ASAP, if they haven’t already done so.

  • guzel sozler

    Without even questioning, we’d be on board in any way we can help Dave. As always, loving your work mate.

  • teoman

    It’s worse than you know: Outlook 2007 changed to Word for HTML layout and we all know what a superb job that does with/to HTML.

  • durma dans et

    pine? nice straw man, very easy to knock down. the standard client these days is mutt

    but no worries, i don’t particularly want to read any email that is part of a ‘campaign’.

  • var misin yok musun

    Well done on hopefully the being of the end to the current HTML email debacle.

  • elektronik imza

    Thanks for this article.

    I’ve struggled with design for email and have concluded that using CSS for structure is nearly impossible with HTML email design.

  • Antalya

    I posted not to pour cold water on you guys, like the angry Pine user above, but just to make the point that there may be other considerations in that move and those considerations may have their own weight.

  • Vergi

    I applaud your efforts and cannot tell you how excited I am that someone has picked up the torch. It’s bewildering, if not down right infuriating, that email has lagged behind the times for so long.

  • Domki pod sosnami

    I completely agree!

  • hip london

    I thought you’d enjoy this. I think this is a fantastic idea.
    Thanks for this article.

  • Sukienki

    The Great Work!
    A leader is one who knows the way, goes the way and shows the way.

  • konto bankowe

    Thank you. Where do I sign up?

  • OFE Fundusz Emerytalny

    Greate Thing.

    Awsome that there is a chanse for making standards all arrond the world. I have had same problems making mail bussiness offers using HTML. So, after few tests I started sending plain text only.
    I hope You make it work. HTML mails looks much better then plain ones;)

    ps. sorry for my english – still learning :)

  • jarek

    Best article, thanks

  • żabiczyn

    Thanks for very interesting article.

  • best poker bonus

    I set up a number of css layout email newsletters for healthcare agencies but I never had a way to test them. The content of the newsletters were separated from the presentation but I had no way of testing whether or not it really helped.

  • bet365

    It really is an issue of many versions of different OS, email client applications, and different screen reader application implementations. The many permutations and combinations may (and probably do) introduce variable results, bugs, and performance use issues.

  • Sklep Calivita

    I think that the positive Internet standards are very important for e-mails.
    It is important that your e-mail address is legible for people with disabilities.
    In the majority of people with disabilities very low assess the level of adaptation of software.
    All the more so that the whole world against people with disabilities continue to build a lot of obstacles, and the question of improving conditions is typically far on the list of priorities.

  • Pod Sosnami

    Very interesting article – thanks. I really enjoyed reading all of your articles. Keep up the good work.

  • twojarandka

    I standards also use and command this to all there is the future

  • clearance london

    Thanks for this article. You’re touching sensitive point….

    It’s worse than you know: Outlook 2007 changed to Word for HTML layout and we all know what a superb job that does with/to HTML… and that’s how it should works with all email clients.

  • Gwara

    Recently established website: nasza gwara.
    Dialect page is devoted to the Polish people, you can find a friend from the past, who left in search of better jobs. I invite all.

Want to improve your email marketing? Subscribe to get tips on improving your email marketing delivered to your inbox.
X

Join 200,000 companies around the world that use Campaign Monitor to run email marketing campaigns that deliver results for their business.

Get started for free