Doctype Switching in Modern Browsers

Thomas Vervik, July 2007 Doctype switching in modern browsers Summary: Some modern browsers have two rendering modes. Quirk mode renders an HTML document like older browsers used to do it, e.g. Netscape 4, Internet Explorer 4 and 5. Standard mode renders a page according to W3C recommendations. Depending on the document type declaration present in the HTML document, the browser will switch into either quirk mode, almost standard or standard mode. If there is no document type declaration present, the browser will switch into quirk mode. This paragraph summaries this article. I will explain how the main browsers on the marked today determine which rendering mode to use when rendering the (x)html documents they receive. I have tested nearly all my assertions in Internet Explorer 6, Firefix 2 and Opera 9.02. The validation is done at the official W3 validation page http://validator.w3.org. Some of my assertions are tested using pages on the net. This is done when testing the media types ‘text/html’ and ‘application/xhtml+xml’with html and xhtml with both legal and illegal syntax. My previous article was full of vague assertions and even things that were directly wrong. This should not be the case in this article where nearly all the assertions are tested. One section I should be humble about is the ‘Doctype dissection’. Finding good sources decribing these in more detail than pages and books just briefly describing their syntax proved hard, but I have done my best and have also described in the text which section I’m certain about and the one I am more uncertain about. I have in additional been very strict on referring my sources, and there is an own source section at the end of this article with links and references to nearly all my sources. Why different rendering modes? First let’s briefly describe why we have a situation today where it is necessary to determine how to render the pages. In the early history of www there were two main browsers on the marked, Netscape and Internet Explorer. Both of them, and especially Netscape, added a lot of new functionality that opened a lot of new possibilities on the net. Examples are cookies and JavaScript in addition to a lot of html tags. Internet Explorer did something similar. But these changes were proletarian and there were no standardization like we have today with the W3 organization. Netscape became less used when Microsoft integrated Internet Explorer in their operating system, and the Mozilla society rose from the ashes of Netscape. From Internet Explorer 6 and above the support for the W3 standard have increased to an acceptable level. But the rendering according to the standard differs a lot from the mark-up Microsoft and Netscape added during the time which is often referred to as “the browser war”, and to support the millions of pages written for the old browsers, the concept of three different rendering modes emerged. This check is done through the doctype defined in the beginning of the (X)HTML document and is called doctype sniffing. Why sniffing the doctype? A dtd was designed to define legal syntax in xml documents. A doctype contains the name of the root element (generic identifier) and a reference to the dtd, which again contains the actual information about the syntactic rules for the document. It defines the structure of the document, and has nothing to do with the presentation of it (the layout). This is a weakness. But this is the way IE 6 and above, Mac IE 5, Opera 7 and later and Firefox have chosen to solve the switching of modes. I have attached a link under ‘Why sniffing the doctype?’ under the source section where the writer discuss this topic Media-types W3 have defined four different media types for html, xml and xhtml. Which one being used has implications for the way the browsers interpret the received document. It is also relevant in the discussing of doctype switching because it describes why html and xhtml is so similar today, and what the difference between them really is. It has also implications in understanding which applications and under which circumstances the two technologies should be used. I will here only describe two of them, ‘text/html’ and ‘application/xhtml+xml’, since the two others doesn’t apply directly to html and xhtml (even thus they can be used for xhtml, but it’s not recommended). The ‘text/html’ media type is primarily for html content and not xhml content. ‘text/html’ is being interpreted by an html parser, which there are many implementations (very easily found by goggling the phrase ‘parser html’). The html parser is working quite different than an xml parser. The biggest difference is that an html parser can’t assume that the content it receives is well formed. An xml parser has simple rules stating how it should cope with the illegal syntax, in an html parser this depends on the browser. I have added a link under the source section “Handle invalid html syntax” which describes how these issues are handled in different browser. A normal misconception is that xhtml is being parsed by an xml parser in today’s browsers. This is wrong; when the ‘text/html’ media attribute is used the content will be parsed by an html parser. Xhtml documents should follow the “HTML Compatibility Guidelines” in order to be correctly parsed by an html parser. This is because there are some differences in the way browsers interpret xml syntax. Examples are use of space between the element and the trailing, like instead of . Also use minimized tag syntax, like instead of the perfectly legal xml syntax . This because the latter can give uncertain results in many browsers (W3 doesn’t mention names on browsers, so this isn’t tested). Other examples is not to use internal style sheets if your styles sheets uses ‘<’ or ‘&’ or ‘]]>’ or ‘--‘. The same applies to internal scripts. For example will xml parsers silently remove the contents of comments, and therefore will the historical practice of “hiding” scrips and style sheets within comments to make your documents backward compatible not work in xml based user agents. So if you make an xhtml document using these elements, it will work nice when interpreted as html (using the media type ‘text/html’), but fail when sent to an other user agent (lets say a pda) using the media type ‘application/xhtml+xml’. The use of xhtml by using the ‘text/html’ media type have also implications for the charset, as html haven’t defined a default charset as the xml standard have. There are several example listed at W3’s HTML compatibility guidelines page, I have added a link under the source section. The second media type is ‘application/xhtml+xml’. This is the media type that should be used together with xhtml. By using this media type the xhtml document don’t have to follow the “HTML Compatibility Guidelines”, since this media type makes sure the browsers interpret it as an xml document. When using this media type you should not use a doctype at all. I have added a link to the specifications of media types at W3 under the source section. Quirk, almost standard and standard mode IE 6 and later have two rendering modes, quirks mode and standard mode. Opera 7 and later and Firefox also have a third mode called ‘almost standard mode’. Quirk mode is rendering the page like the old browsers did, like IE 5 and earlier and Netscape. The technical differences are the way the browsers interpret the tags and attributes in the (x)html document. There is an own section later in this paper showing theses differences. Almost standard mode is only available in Firefox, Safari and Opera browsers and is the same as standard mode and uses all the css 2 standards, but in addition have support for the table cell vertical sizing. Many layouts on internet are designed using tables, and putting images into table cells. In quirk mode this works well, but in strict mode there will be some space below the image called "descender space". This is because in strict mode an image is by default an inline element, like text is. An inline element has a baseline which letters are placed upon. Below the baseline is some reserved space for the lower parts of the letters, like j g p, etc. A image will be placed on the baseline and therefore have the “descender space” below it. IE doesn’t add the “descender space” below images in strict mode when there is no text around, so this is not an issue here. Standard mode uses the standards as defined in the particular browsers. These may not be the same as the W3 standards, but they may go as close as the browser will go to the standard. There are different standard modes depending on which dtd used. The transitional standard typically allows deprecated tags to remain backward compatibility with old pages. But even if you use a dtd that don’t allow deprecated tags, the browsers will still interpret them. Example tested with is the <center> tag and strict mode. The page will not pass be validation by the official W3 validator, but the tag is still interpreted by the browser. The Difference between strict and transitional HTML / XHTML In short, transitional is a forgiving form of doctype as it allows deprecated tags and attributes to pass the validation test and makes the browser doing its best to render your page as you wanted it.

Load more