The spread of prominent marketshare between multiple browser versions and platforms has made pixel perfect web design a challenge over the last decade. Each browser may layout elements differently. Some of these layout instructions have been dictated by standards; others by different implementations in the browsers.

Specifying a Document Type Declaration, or DOCTYPE, when writing is considered a standard and best practice in order to properly instruct the browser how the HTML should be rendered. In reality, most web developers know that using a does not guarantee cross-browser compatibility or presentation consistency. However, it is a step closer to simplifying a singular code-base for each browser.

No Doctype?

Some developers believe that the best is no doctype at all. The approach is to use “quirks mode” or the native rendering instructions and write specific styles and markup for each supported browser (or version of a browser). The thought process here is that by not forcing a standard, fewer bugs may occur, a nightmare faced when working in legacy browsers such as Internet Explorer 6.

The purpose of quirks mode was intended for backwards compatibility purposes of legacy web sites and not for developing against it as a standard. The no doctype approach opens the door to bad web development and unreadable code littered with conditional logic and different markup, styles and code for each browser. The future maintainability of the site can be compromised and updates typically become full-scale rewrites. All good developers should strive to support as many modern on as many platforms as possible, using the least amount of code.

What Doctype Should Be Used?

There is no practical reason not to chose the doctype for new development. For the foreseeable future, this will be the standard of the web.

Although is currently a working draft and not a standard, all modern web have done a very good job in supporting it consistently. This doesn’t necessarily mean that developers need to take advantage of 5 APIs or features, but developers can feel comfortable writing markup and styles against it for a consistant cross-browser look and feel with minimal effort. If it is necessary to support legacy browsers, scripts are available to enable support for HTML5’s new tags. Future maintainers of the document will quickly and easily know what kind of markup it can expect and can future-proof your markup for the next HTML standard.