Earlier today, one of our customers asked for our recommendation on doctypes. While choosing a doctype when designing for the web these days is a no-brainer, there’s still doubt as to whether the elegant HTML5 declaration is as applicable to email design.
Realizing that our last update was in 2010, we decided to take a fresh look at why doctypes in email matter and which is the most reliable doctype for email designers to use.
Why do doctypes matter in email?
Before we get too deep into the results, I’d like to take a step back and talk about why the choice of doctype matters in the context of HTML email, given the “brokenness” of CSS support across email clients today. Personally, I think there are two reasons why we should write valid code for HTML email and they are:
- Future-forwardness – While email clients may change dramatically, the email templates you build for your client today may continue to march on unchanged for years into the future. Using unsupported/deprecated elements and attributes within an email campaign may have unexpected consequences as far as email rendering goes.
- You just want to write valid code – Pride in one’s work counts for something. Plus, validators are very useful in HTML email design; there’s no reason to have them flag everything, when all you’re looking for are unclosed tags.
Deprecation of elements across the doctypes is something that distinguishes each of the most popular choices clearly. For example, here are some deprecated elements and attributes that we commonly see in HTML email, by doctype:
| XHTML 1.0 Transitional |
XHTML 1.0 Strict |
HTML5 | |
| Elements | <center> <font> <u> |
No deprecated tags are supported |
No deprecated tags are supported |
| Attributes | align (allowed on tables) background bgcolor border (allowed on tables) height (allowed on img) hspace vspace nowrap target link, vlink, and alink width (allowed on img, object, table, col, and colgroup) |
No deprecated attributes are supported |
No deprecated attributes are supported, as well as: border (from tables, too) cellpadding cellspacing clear (from <br>) |
Sure, we may use deprecated tags heavily in HTML email, but at least this is given a pass when using XHTML 1.0 Transitional. This is not the case when using the XHTML 1.0 Strict or HTML5 doctypes, so Transitional is the way to go.
Why not just regress to HTML4, then?
Apart from simply being morally reprehensible to most of us, there main reason why we shouldn’t be using the HTML4 doctype is good coding practice. This means “well-formedness” (ie. no overlapping elements), correctly terminating elements, quoting attribute values and terminating empty elements. These are things a validator should definitely be picking us up on, but are ignored in documents using HTML4 doctypes.
But how about <video>?
The <video> element was introduced in HTML5 and to many, is seen to be where the future is headed. Our friends at Litmus already send emails with HTML5 video backgrounds and I suspect we’ll see more people trying this soon enough. As it turns out, it’s totally possible to have your cake and eat it, too – using the XHTML 1.0 Transitional doctype, you can still use <video> element in Apple Mail, iOS Mail and Outlook 2011. I know, getouttahere.
So, here’s the other thing – webmail clients like Gmail, Google Apps, Yahoo! Mail and Outlook.com already strip your doctype, regardless of what it is (and use the HTML5 doctype instead). So, you don’t really get a choice here, anyway.
So, what doctype should I use in email?
If you’ve skipped the long doctype lesson, here’s the short answer: use the XHTML 1.0 Transitional doctype, ie:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional //EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
One thing to note is that to avoid spacing issues around images (due to images in tables being treated as inline elements), you should always include the following in CSS stylesheets:
img { display: block; }
Once you’ve got these fundamentals in place, you should be ready to code relatively valid and reliable HTML email newsletters and templates.
