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. 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:
I’D LIKE TO THINK YOUR DOCTYPE CHOICE DOESN’T AFFECT OUR FRIENDSHIP. BUT WHO AM I KIDDING.
|7||live.com||Login page has no doctype. Once logged in:
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
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)
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’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)
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.