Javascript - DOCTYPE

DOCTYPE is neither an html tag nor part of javascript. However, this directive should be on the first line of every html file because it determines how html tags and javascript code operates.

Unfortunately, its effect is very poorly documented.

Basics | Examples | The *pre* Element | Random problem | Data from Wikipedia | Specific Issues | Quirks Mode | Obsolete HTML Codes and Table Properties


My earliest html files (before 1997) do not contain DOCTYPE - they simply start with <html>. During 1997, I started using on all of my web pages. I never knew, or cared, what it meant - it was just something that was recommended and I used it on all pages since then .. until 2017.

When I started serious javascript development in 2017, I started noticing issues where the online help would say that some feature was supported in IE8, but nothing would make it work. While researching the problem, I discovered that the expected DOCTYPE tag had changed and that some browsers (not all) were refusing to acknowledge features added after HTML3. Another page documents 2 specific IE8 problems (unsupported styles) "fixed" March 2017 by changing the DOCTYPE directive.

I apparently misunderstood the help on some reference page and began using DOCTYPE with no parameters. While debugging a different problem, MS Edge produced the following error.

When I "fixed" that error, the formatting of the page I was currently working on changed - examples in the next section.

Since most of my (over 1,000) pages don't use style sheets or javascript, that tag should not matter and, as far as I know, they are still working. As a result, I do not plan to change the tag on any existing pages.

My new pages with extensive javascript (mainly used to graph data) will use the HTML5 specific tag.

New pages which don't have draggable windows will still use the old, 3.2, directive because many of the html tags I frequently use won't work with the new (non-compatible) directive.


These are links to the example pages The formatting shown in these images is produced by the exact same html tags in the indicated browsers. The ONLY differences are the DOCTYPE tag and whether or not the style lengths end with px.

All the images above were saved via a screen capture and cropping in GIMP.

I captured images using both Chrome 49 on Windows XP and Chrome 57 on Windows 10. The Windows XP images above are the actual images without scaling them. Using Windows 10 (with a high definition monitor) the captured images are huge. As a result, the images above are shown 2.5 times smaller than actual to make them appear the same size as they do on a page (though they are a bit fuzzy). (Windows 10 really sucks.)

On Windows 10 with a high definition screen, the text and icons of some applications are multiplied by 2.5 (the recommended value) to make them readable, and others aren't. (What a great OS - good thing they are trying to force everyone to switch.)

The slight difference in size between Chrome 49 and Chrome 57 is due to the difference between the default border widths - 2px vs 1.2px.

The *pre* Element

I normally highlight quotes and code using a table with a pre element to control line breaks. Unfortunately, the height of the element depends on the DOCTYPE directive, as shown below. As a result, I will continue to use the old version 3 (Quirks Mode) of the directive for regular web pages (those that do not require movable windows).

Random problem

While working on this page, I had an error in the html. It was completely ignored until I tried the examples in IE8. At that point, the extra double quote caused the first tab to not show.

Data from Wikipedia

When the DOCTYPE declaration is completely missing, the page renders the same as when html is missing. Wikipedia (the source of all true knowledge) clearly states that I have no idea what the difference is between HTML5 and XHTML5. I have read several discussions, but still don't know what is going on.

That said, the difference in how the tags are rendered is obvious - one looks good and the other is crap!

Specific Issues

In older versions of html, when a size (width, height, padding, ...) was specified in a style as just an integer, it was automatically interpreted as a number of pixels. However, when <DOCTYPE html> is used - those values are now invalid! Now, the numbers must contain px after them. (I was not able to find where this is documented elsewhere.)

When the <DOCTYPE html> tag is missing, the following specifies the number of pixels for the total width - including the padding and border. However, it is invalid (shown with an error icon and a line drawn thru it in the debug inspector) when <DOCTYPE html> is specified.

The following causes the element to be rendered at about the same size when <DOCTYPE html> is specified. - assuming that the padding plus border is about 2 pixels in width (multiplied by 2 for a total of 4 pixels because the padding and border are on both sides of the element.) In summary As a result, a width of 21 when omitting the <DOCTYPE html> tag renders the same size as a width of 17 when it is included.

Quirks Mode

Quirks Mode allows pages written for IE5.5 to still be (properly?) displayed. "Modern" browsers (a moving target) implement standards that require certain common html tags and CSS styles to be ignored. There is no ambiguity about what those tags and styles mean, but "the powers that be" have decided to intentionally break existing web content anyway.

To reduce the amount of active protests, these "powers" allowed Quirks Mode where existing pages can still use the old methods, but new pages must use the new rules if they want to use certain new features.

The DOCTYPE directive determines which set of rules a browser uses. This is more like legacy support than backward compatibility.

According to WHATWG,

The unitless length quirk explains that

Found via Activating Browser Modes with Doctype

This includes a table showing which DOCTYPEs invoke the Quirks Mode. Of particular interest to me (because I have used them) are

Unfortunately, this problem is not fixed by simply changing a header because some html codes (such as font) will simply not work - part of the "plan". Conspiracy or incompetence? What I write today (I spend a lot of time making code cross browser. For every day I spend "writing application code", I spend 3 to 5 weeks making it work in current browsers, and a few days making it work in older browsers. I wish this were an exaggeration, but it probably understates the time actually spent trying to produce cross-browser code. Adding to this the fact that what works today will likely be intentionally broken in some new standards release, and you can see the real problem.)

This lack of backward compatibility means that

Obsolete HTML Codes and Table Properties

These are some of the properties I use regularly that they plan to stop supporting. (ref) There are many more that I typically don't use.

I also use name on a elements to produce menus on almost every page.

Author: Robert Clemenzi
URL: http:// / Languages / Javascript / DOCTYPE.html