Skip to main content

  • April 14, 2011

Are Doctypes the New Lunch Tables?

Viewing source has gotten pretty rad these days! Looking around the web, a good command + u (yes, I use Firefox/Mac) can provide an afternoon of exciting show and tell. Decorative Illustration One thing I like to look into is at which DTD table everyone is sitting these days. When the HTML5 doctype was introduced, some folks grabbed it and never looked back to the land of system identifiers again; others were cool with rocking a doctype that has been working for them for the last decade or so. This has caused some separation between those who see the choice as the past versus those who see it as the future. The cool table versus the lame table.

Some people even expressed passionate cynicism on the matter:


Taking a look at the doctypes of top sites from Alexa, we get a variety of results:

Alexa Rank Domain Doctype
1 <!DOCTYPE html>
2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "">
3 <!DOCTYPE html>
4 <!DOCTYPE html>
6 <!doctype html>
7 Login page has no doctype. Once logged in: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
8 <!DOCTYPE html>
9 <!DOCTYPE html>
10 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
11 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "">
12 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "">
14 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
15 <!DOCTYPE html>
16 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "">
17 <!DOCTYPE html>
20 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">

Lots of sites have made the switch while some are still rocking 4.01. At Happy Cog, we don’t assume that one choice is always the right one for our clients. Before we start coding a project, we discuss with our client which doctype they’d like to go with and the pros and cons of each. We usually suggest one of three directions:

XHTML 1.0 Strict

Funny cat picture depicting that this is certainly not the future!

The doctype we’ve known and loved for a long time now. It keeps code well formed and, used in conjunction with tools like the W3C validator, developers can make sure the code stays nice and clean — no tag soup or cOde that L00ks like thSSSS! Browsers become predictable here and while we might need a height: 1% in a few places, we won’t need JavaScript to make our elements display nicely. Another bonus of using this doctype is most of our client teams are already familiar with it, so the learning curve is low/non-existent. No surprises here, such as wondering whether or not you can leave a type attribute off of all your elements. If this will save a significant amount of time for our client’s team after project hand-off, that might be enough to sell us on this one.

However, one big element that’s missing here, is the Future! There’s not much new and exciting about the XHTML 1.0 Strict doctype and, for new sites, it can cause more work to write that longer doctype and close all the tags. There’s a lot of new awesome stuff that wasn’t invited to this party.

HTML5 Doctype utilizing full HTML5 element support (i.e. article, section, header, nav)

Cat wearing shades, cause this is the future and it sure is bright

We like when the web moves forward, so we obviously really dig a lot about the new features in HTML5! Sectioning elements make semantic heading outlines a breeze and we love replacing some of our divs with more appropriate elements like aside and nav.

There are some large drawbacks here, though, such as requiring JavaScript for elements to display correctly in IE6-8. We have to think about how many of the site’s visitors are using earlier versions of IE with JavaScript disabled. Or is there a possibility that one or some of your largest visitor groups or stakeholders will be browsing your site that way? With Happy Cog Hosting (which uses HTML5), we decided the risk of that scenario was small because it is a technical product (people making decisions on hosting are usually well aware of browser constraints) and because we provided a PDF of pertinent information that all users can obtain if their browser is not supported.

There’s also been mixed reports on how different screen readers handle HTML5 and ARIA roles. Again, we also have to look into the learning curve and analyze if choosing HTML5 will cause major headaches for our clients when integrating our templates.

HTML5 Doctype using limited HTML5 elements (new form types, HTML5 video, shortened doctype)

Cat pondering the future, but with committment issues

Our safe route. It sets the site up for future support of new elements, but we start with limited use. We can use the leaner doctype, leave type attributes off our script tags and incorporate new form types that will degrade to text inputs for browsers that don’t support it. Our data attributes and ARIA roles will validate, though we can also validate our markup against the XHTML strict doctype to make sure our years of neat tag writing stay in tact and our code stays pretty.

These three options are just some of the approaches to consider when choosing a doctype and markup direction. Perhaps you like to sit at the table that’s always looking at what’s next. Or maybe you like a bit of fusion in your diet. Or maybe you like to eat someplace that’s recommended and don’t find drafts that appetizing. What’s your favorite doctype and how do you choose?

Gasp! That never happens on the Internet.
Repeat Google domains were omitted. All used the HTML5 doctype.

Back to Top