Question

Given a large legacy project utilizing ASP.NET, javascript, css, etc, technologies, I was wondering if changing the DOCTYPE of the web pages, say, from HTML 4.0 Transitional to XHTML 1.0 Transitional (or the other way around) in any way could break the javascript functions of the web pages.

There are plenty of articles and discussions about how different DOCTYPES affect the (css) rendering of pages, but I cannot seem to find anything similar on the subject of breaking any code.

I am looking for links to articles about things to watch out for in general so as to better spot potential problems in existing code and avoid creating problems when writing new code.

Answer 1

Whether changing DOCTYPE will break any javascript functions really depends on how defensively those functions are designed 🙂

For example, when document is rendered in quirks mode, document.body (BODY) becomes a so called “root element”; when rendered in standard mode, that root element is usually a document.documentElement (HTML). This is a rather substantial distinction. If a script that determines browser screen size always queries clientWidth/clientHeight properties off of document.documentElement, it will obviously report incorrect results in quirks mode (since, IIRC, document.documentElement.clientWidth/clientHeight would represent dimensions of HTML element, rather than screen ones).

Most of the JS libraries usually explicitly state whether quirksmode is supported (we – Prototype.js – for example, don’t support quirks mode).

Speaking of HTML vs XHTML, in order for browser to render document as XHTML, you must first of all serve it with proper “Content-type” header (i.e. application/xhtml+xml). If you only change doctype to XHTML one, but still serve document as “text/html”, most browsers I know will still parse (and render) it as HTML document.

Note that to date, IE doesn’t understand “real” XHTML content, which is why serving documents as text/html (with HTML4.01 doctype) is a recommended way to go (unless IE is not among supported browsers, of course).

As far as DOM peculiarities in “real” XHTML documents, I’ve heard that some things like document.write “don’t work” and that accessing node attributes should always be performed via getAttribute/setAttribute (rather than via simpler property accessors). IIRC, there are also some issues with innerHTML.

The lack of information about DOM in “real” XHTML documents is probably due to its impracticality in documents/applications for general web (i.e. IE’s lack of support for it).