There’s no question that designing with web standards is the only correct approach to new website design. Let’s ignore the fact that there are countless sites that ignore the existence of web standards. Instead, let’s look for affirmation in the traditional medium of print, our most reliable source of permanent knowledge. I challenge you to go to a book store and find a recently published book on client-side website development that fails to endorse standards.

Before web standards became the de facto standard, the movement was mobilized with a war cry of accessibility, findability, better design, compatibility and obvious economic benefits. This rhetoric rallied a diverse set of professionals behind the cause and, in the process, introduced a diverse set of stakeholders.

A constant challenge when pursuing virtue in web design is appeasing these stakeholders. Does this website disenfranchise those with poor eyesight? Does this design accurately communicate our brand? Will this website work in older browsers? What will be the cost of maintaining this website?

The DOCTYPE is one of those areas of contention where recent discourse has done little to synthesize an approach. I’ve been confronted with the question of which DOCTYPE to use a couple of times in the last couple of months, and both times I searched for the answer, the less clear it got. An oversimplified approach to conventional DOCTYPE wisdom goes something like this: Use XHTML, it’s the future. Use the transitional DOCTYPE because Strict HTML is not properly supported. Don’t use a transitional XHTML on new sites because it doesn’t encourage full separation of structure and presentation. Because the Strict XHTML DOCTYPE is considered harmful, use Strict HTML instead. Oh yeah, use XHTML, it’s the future. Not to mention, HTML is also the future.

In order to put the DOCTYPE question to rest, I decided to come up with a quick set of context-based rules I can reference that can help me solve the moral dilemma that is often involved in choosing a DOCTYPE. This is a work in progress.

You’re Handing Off a Website to a Client

Your DOCTYPE: XHTML 1.0 Transitional

When you’re handing off a website to a client, it is common to provide some documentation. Some clients will have a dedicated web team and others will attempt to manage the site themselves by hand or, more likely, through a content management system. Even if you provide the new website owner with good documentation, you can’t expect the client to ravenously pursue perfect markup – for a web developer, the end is the code, for the client, it’s only the means to some other end.

The DOCTYPE was originally introduced as a construct to help browsers determine how they should render your code (old-school way or with web standards in mind). Obviously, you’re using web standards, which realistically limits your choice of DOCTYPE to: Transitional HTML, Strict HTML, Transitional XHTML, and Strict XHTML.

In my opinion, you sell yourself short with Transitional HTML, so this choice can be eliminated. It would also be a disservice to your client to label a site as Strict, when there’s nothing to suggest that your good intentions will continue to be addressed. Being the more forgiving (yet still future-facing) of the available DOCTYPES, it allows the new site owners to focus on site objectives and not as much time figuring out why the XHTML doesn’t validate.

Accessibility Is a Core Obective

Your DOCTYPE: HTML 4.01 Strict

Every web developer should have accessibility in mind when creating a website. However, accessibility is not an absolute affair and I think that it makes more sense to view it as a continuum or, if you prefer, a spectrum. There are certain websites that require the highest levels of accessibility more so than others, for example: government sites, education sites, document archives, etc. In short, they are sites where the universal availability of the information is almost as important the information itself.

The recommendation is largely derived from the DOCTYPE used by Roger Johansson, who unknowingly is my accessibility mentor. He certainly has thought about the DOCTYPE in the context of accessibility more so than I have. He has argued for Strict DOCTYPES in the past and it would appear that other accessibility professionals share that view – judged by a quick survey of the websites they produce. However, the divisive Sending XHTML as text/html Considered Harmful, apart from other considerations, still leaves Strict XHTML versus Strict HTML unresolved.

If you liken the (X)HTML specifications produced by the W3C to a constitution, accessibility professionals would likely be considered as strict constructionists in their interpretation – where the interpretation is based on the actual words and not so much the intention that framed those words. While this metaphor is, at best, flimsy and potentially insulting, it supports a notion of conservatism and restraint in regards to using technology in the context of accessibility. Predictability, tradition, convention and standardization are all tenants of an accessible experience. With XHTML still in its awkward teenage years, and with HTML getting a new lease on life – not to mention the millions of pages that use it – HTML 4.01 Strict is like a continent in a sea of change. (This last sentence was brought to you by the word “cliché” – please show support for my sponsor by posting more lazy prose in the comments section.)

Now What?

The advice presented here is more for myself at this point. There are other contexts which merit having a go-to DOCTYPE solution (content publishing, new web application, etc.). However, before publishing the rest of my propositions, some peer review and direction is in order. After which, I’ll continue to post brazen suggestions with reckless abandon.

Keep in mind, there are some concepts that took a while to develop but are only mentioned in passing. When offering your thoughts, please keep in mind the purpose behind this: to synthesize a heuristics-based approach to choosing a website DOCTYPE based on context. Arguing for the end-all, be-all DOCTYPE would be missing the point.