Which doctype should I use in HTML email?

Over the last few months, a couple of folks have asked us about which is the correct doctype to use in email. Finally, I decided to get into gear and find out for myself. Keeping in mind that some web clients strip out the doctype (if not head content) of your email, we found that there are subtle differences in how email clients render HTML emails with a variety of doctype declarations… Or no doctype at all. Read on to find out what we learned.

Testing doctypes in HTML email

We decided to test three emails in this exercise - one with an XHTML 1.0 Transitional doctype, one with an HTML5 doctype and finally, an email with no doctype at all. Here’s a sample of the code we used:

XHTML 1.0 Transitional

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<
html xmlns="http://www.w3.org/1999/xhtml">
<
head>
<
meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
... 

HTML5

<!DOCTYPE HTML>
<
html>
<
head>
<
meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
... 

No doctype

<html>
<
head>
<
meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
... 

So far, so good. The email itself was very simple, with a variety of common CSS 2 & 3 techniques applied including margins and padding applied to table cells. That said, we left most elements as per their default settings. So, lets get on with the show.

The results

As mentioned, the difference a doctype can make is in most cases, quite subtle. However, this may help you debug down the line why, for example, you’re seeing more/less margin than expected in certain email clients. Here’s a summary of the differences we saw:

A doctype is required to display CSS3 in AOL Web

Yes, CSS3 in email lives, at least in a handful of email clients. In AOL Web, properties like border-radius and text-shadow only display if the XHTML or HTML5 doctype used:

Differences in AOL Web

If you’re going to use CSS3, XHTML 1.0 Transitional is the doctype for you (until HTML5 becomes standard, anyway).

No doctype, no paragraph margin

The main effect that having a doctype (or lack of) in email seems to be the amount of margin that’s added beneath <p> elements (tags). Here’s what this looks like in iPad Mail:

Margins in iPad Mail

Odd, hey? Here are email clients that we’ve observed this behavior in:

  • Gmail
  • MobileMe - No margin with HTML5 doctype only
  • Apple Mail - h1 also affected
  • iPad - h1 also affected
  • iPhone - h1 also affected
  • Symbian S60

By default, <p> elements have margin: 1.12em 0; applied (according to the default HTML 4 stylesheet), however browsers and email clients don’t necessarily have to adhere to this. After all, you may want to add a CSS reset for more pixel-precise work.

XHTML for validation

The other thing is, if you put a premium on validating your code (as well as you can when coding for email, anyway), then we recommend the XHTML 1.0 Transitional doctype. Naturally, not having a doctype will throw errors and and the HTML5 doctype is still marked as experimental. Mike Kleiman has a light summary on standards vs. quirks mode and email clients, should you wish to get all semantic.

Well, this is by no means an exhaustive test and we’re more than happy to test out specific elements that haven’t been covered here. But the moral of the story is that if you are keen on retaining the default margins on elements (and like CSS3), use the XHTML 1.0 Transitional doctype. That said, there are loads of email clients that arbitrarily add margins and padding to elements, so be sure to check our forums before you pin a rendering issue on the doctype used in your email.

Finally, we’d love to hear about your experiences with doctypes and standards compliance in regards to email, so feel free to give us some food for thought in the comments below.

Update: Our friends at Email on Acid have been doing some pretty comprehensive doctype testing themselves. Well worth a read!

Posted by Ros Hodgekiss

16 Comments

  • Craig
    15th November

    I’m curious to know if not having a DOCTYPE or HEAD makes any difference to Outlook. I’ve never used either (and experience all the same issues that Outlook always exhibits).

  • Ros Hodgekiss
    15th November

    Hi Craig, we can’t see any email rendering differences caused by the inclusion/exclusion of a doctype in Outlook ‘03/‘07. From what I can see, both clients retain the head content of an email.

    Sometime I’ll test what difference it makes in a variety of email clients to not have a head section, but in the interim, its probably worth keeping it there.

  • Myself
    16th November

    What about using HTML 4.01 Strict?

  • Wilbert Heinen
    16th November

    @ Myself:

    For example: If you want to use target=“_blank” on your links, you should use Transitional, because strict won’t allow target=“_blank”.

    If validation of your html doesn’t matter to you, you can use it.

    Strict forbids the use of a lot of (for e-mail html) necessary attributes and similar things.

  • Jason
    16th November

    So, which doctype do you recommend?

  • Richard
    16th November

    I would recommend using no doctype at all. In my experience, most email clients disregard it and I have found the art of a successful, cross browser, cross vendor email is to take it back to it’s most generic form.

    This also includes the use of CSS in html emails - CSS2 across email clients is poor in most cases, so why would anyone even attempt to use CSS3 or HTML5 is beyond me.

    Yes, you have a list of browser vendors which support CSS3 commands, but in the real world, building html email campaigns for multitudes of people will mean that it needs to be as backward compatible as possible, Hotmail in IE6 included.

    It doesn’t mean that your emails cannot be aesthetically beautiful, it just means you need to be more creative with your coding.

    @Myself, @Wilbert Heinen target=“_blank” not being recognised? It’s an email, all email vendors open links in a new window by default anyway.

  • Frederick Polk
    16th November

    @ RH, Thanks for looking into this. You rock! And I will try the XHTML doctype however…
    @ Jason, this doctype has been the most successful and forgiving, for me in my work:

    html4 loose

  • Wilbert Heinen
    16th November

    @Richard:

    That’s not my experience. For example Outlook 2007:

    There’s a delay if you click on a link without target=“_blank”, because the rendering engine tries to open the link in the same window.

    When you view the online version links will open in the same window, you don’t want that to happen, do you?

    I agree on being creative with your code to create beautifull cross-browser/cross-emailclient emails.

  • Richard
    16th November

    @Wilbert Heinen, when looking to create as little and cleaner code as possible, it’s my preference to drop the target=“_blank”, particularly just to accomodate one vendor.

    I’d be interested also to view the amount of traffic on each “online version” compared to open rates of the email itself. The number, again possibly too low to justify. Also, if we are going to use this for the online version, accessiblity in mind we should include the “opens in new window” guidance note for each link. Which, depending upon your design could be considered as code “bloat”.

    Not to say either method is right/wrong. Just html email build is very difficult to get right and keeping things simple, often works better. When trying to accomodate every variable, there are some things that can make way without compromising the final product.

  • Wilbert Heinen
    17th November

    @ Richard

    Using the target=“_blank” is a kind of a standard for me and the company where I work. Our experience with it is that it is userfriendly for online versions (online versions are also linked from txt-version).

    Maybe the number of people who view the online version (or getting the text-version) is small, but I think we can’t exclude them. But that’s a choice we made as a company.

    Maybe there are some global numbers of people that receive txt-versions or viewing e-mails online?

  • Wilbert Heinen
    17th November

    Another argument for me to use a doctype:

    “If a !DOCTYPE is not specified, the border-collapse property can produce unexpected results.”

    source: http://w3schools.com/Css/pr_tab_border-collapse.asp

  • Jonathan Kapaldo
    18th November

    @RH Thanks for the informative post.

    I have tried not using a doctype, but small things, as mentioned in previous comments, would not look right or work. I have generally used the html4 strict doctype (Really, have not paid much attention to doctype before). Though, over the last few months, I have completely overhauled all my email templates and one-off designs to use HTML5 doctype. So far, I have not had issues with it and seems to play nice with email clients.

  • Ros Hodgekiss
    18th November

    Thanks everyone for weighing in on this discussion. FYI, one of our customers recommended reading this earlier post on doctypes from Email on Acid. There’s some excellent observations in here regarding rendering differences across the spectrum of email clients, so it’s well worth a read.

  • Brian Thies
    1st December

    <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”> all the time, every time.

  • Kenny L.
    1st December

    Thanks, I’ve recently updated all my company’s email templates from HTML 4.01 to XHTML 1.0 Transitional. I’ve been wondering if I should go to HTML 5, but this makes me think it’s not quite time yet. I have one template that uses no doctype, but it is a special case until I can rewrite it. All of this is great, but what would really be nice is the full use of CSS 2.1, not to mention CSS 3. Someday, maybe…

  • EmailBeauty
    23rd January

    We always use XHTML 1.0 Transitional by default and HTML 4.01 for clients sending to European ISPs. HTML 5 / CSS 3 won’t be standard for a while.

Sign up for free.
Then send campaigns for as little as $9/month

Create an account