Anne van Kesteren

How browsers work

Every now and then this topic comes up and it might be nice to tell the story from a browser point of view. The browser point of view made me choose HTML when I finally understood it. I also work for a company that builds browsers in case you expect me to lie. (Some people do, apparently.) (Note that weblogs are still not normative though, they are about cat pictures.)

Browsers rely on the MIME type. Is your file served as text/html it will go to the the so-called “tag soup parser” and the browser will build a DOM from that doing all kinds of error recovery if necessary. It is actually a bit more complicated, keep reading. Is your file served with an XML media type it will go to the namespace-aware XML parser which will then create a DOM from the string of text in your file. In addition, it will scream about mistakes and show yellow screens to the end user talking about parse errors and such.

DOCTYPEs solely exist to switch modes for text/html documents. This is why using a “transitional” DOCTYPE is bad. Henri Sivonen told you long ago that this DOCTYPE triggers almost standards mode. Bah! Note that this also affects parsing, not just rendering. For example comment handling is done totally different on the parser level in quirks mode. So first there is a switch on MIME types. If the MIME type is text/html some further switching will happen based on the provided DOCTYPE which affects both parsing and rendering of the document. Therefore using a good DOCTYPE is necessary. In doubt, use: <!DOCTYPE html>.

Note also that all the above implies that from the browser point of view there is no difference between HTML and XHTML when you send them as text/html. For the author, however, this is potentially confusing. The element nodes in the generated DOM do not have a namespace, are in uppercase and special CSS HTML only rules apply. The key here is that the way you send your documents over the wire can have totally different results. Whether you agree with that or not isn’t the point, it is the way browsers work and how they stay compatible with the web. (For example, a lot of the “XHTML” sites are not really conforming to the XML specification and would all break.)

In XML browsers render based on namespace dispatching. This means that elements are styled based on their name and namespace. If the weblog mentioned in the beginning was actually served as XML browsers would not style it. The first tag in the document: <html xml:lang="en">. Browsers will create an element node in the DOM named html, but they will assign no namespace to it. Therefore it is considered just some random element from a browser point of view and no specific styling is applied. (That it validates is merely because the DTD sets a fixed attribute value for the root element declaring the namespace, pretty stupid mistake from the HTML WG.)

Personally, I chose for HTML because of Internet Explorer and the flexible error handling of HTML. (Which in a way applies to XHTML too as explained above.) As XHTML is intended to bring HTML semantics to XML and I could not send it otherwise then text/html there was no point in using it. That, and some other points made by the Henri Sivonen mentioned above.

I hope this makes my position clear and shows that there was nothing evil or going against the stream attitude behind it. Just logic, no buzzing.