innerHTML

Today a co-worker and I were scratching our heads over why Safari wouldn’t display XML with an XSLT stylesheet defined. It should display the XML, at least according to Safari’s developer documentation: “Safari 1.3 and above supports XSL transformations of XML pages at load time.” It wasn’t working for us, though.

Searching eventually turned up this article, but the article’s author could get XML to display sometimes. We couldn’t at all.

But one of the article’s comments helped:

The problem is that the DTD is not available at the specified URL. So you mustn’t suppres [sic] the DTD in the Stylesheet but you must insert a DTD declaration that points to an existent file.

In other words, it turns out Safari requires a DTD. And the browser doesn’t like XSLT stylesheets with <!-- comments. But you can use the <xsl:comment> tag (something new to us that probably shouldn’t have been new). So, I removed the HTML-style comments, added the DTD for XHTML 1.1 and … no more blank screen. All is well with the world.

There’s a mini-war over what MIME type to serve XHTML as: either application/xhtml+xml or text/html.

First, a definition: MIME stands for Multipurpose Internet Mail Extensions. Even thought HTTP is not email, “HTTP requires that data be transmitted in the context of e-mail-like messages, even though the data may not actually be e-mail” (see the W3C protocol). MIME types are usually defined in the server’s .htaccess file. In a (fragile) nutshell, serving a file as either application/xhtml+xml or text/html tells the browser what to do with it: treat the file as XML (a standard with strict coding guidelines) or HTML (a standard with looser guidelines).

What this means is that an invalid, i.e. not strictly coded according to XML guidelines for well-formed documents, XHTML document gets chewed up and spit out by the browser as, well, broken. As James Edwards puts it: “the strictness of a validating XML parser may be too extreme for real-world use. For an invalid XML document, browsers did not even make an attempt to parse the document as best they could, as they would with HTML—instead, they just displayed a validation error and stopped.”

There’s a significant group of developers and other groups who argue that XHTML should only be served as application/xhtml+xml. The list: Ian Hickson, Anne van Kesteren, Mark Pilgrim and the WebKit team. The W3C makes it clear as well: XHTML documents should be served as application/xhtml+xml.

I’m working on a large web application that, from the beginning in 2007, has been using XHTML 1.0 Strict DTD served as text/html. Given the above links and recommendations, this is wrong. But, as Hamlet said, “there is nothing either good or bad but thinking makes it so.”

Other developers have taken the stance that serving XHTML as text/html is fine. Brad Fults, for example, finds Hickson’s argument, “wholly unconvincing” and details why. For example, “the biggest advantages to XHTML are its readability, uniformity, well-formedness as it pertains to authoring, and the consistency of the rendered DOM (which is also a result of any well-formed HTML document).” XHTML Validation, then, is the author’s responsibility, but not a burden on the browser, which (when serving as text/html will render the page as HTML. Fults again:

Is there a harmful issue here? No. Whether or not documents validate is a completely separate issue from the MIME type as which they are sent. It is up to authors alone to worry about validating their documents with a validator.

Back to James Edwards, he takes a stance that it matters, sort of. Serving as text/html ensures that users get a readable webpage even when code might be malformed or not supported by the browser. To lean on his phrasing, an XHTML page served this way can fail cleanly.

I’ve written all this up to determine what a project I’m working on should do in terms of DTD and MIME type. Right now, I’m working on Puma, a network device visualization web application that acts as a detailed catalog of nearly 15,000 devices (routers, switches, APs, etc.). Serving the application as application/xhtml+xml, in no uncertain terms, breaks it. Somewhere in the thousands of lines of code, there’s malformed XHTML. Maybe. As a device page starts to build, a small portion of it succeeds, but at a certain point early in the process, it borks. I’m curious if it’s a JavaScript problem. A lot, maybe 95% or likely more, of the page is built by jQuery and JavaScript that relies on a JSON document for content. It seems as if when the JSON document comes into play, the borking begins. But I could be wrong.

To sum up, I’m going to continue serving Puma as text/html until the borking can be pinpointed. This way Puma can fail cleanly and still take advantage of the well-formed document structure XHTML demands.

I came across this on Ajaxian today:

Blaming the W3C for not pushing the web forward is both humorously off-target and distressingly common. … The action we all want is the sole purview and responsibility of the browser vendors and they alone have the power to push the web forward. Read more

The original article is a useful articulation of the real problem: browser vendors.

Safari 3.1 is out today. It scores 75 out of 100 on the Acid3 test. If you’re curious (like I am), here’s how some browsers currently score on the Acid3:

• Safari 3.1: 75/100
• WebKit (r31114): 93/100
• Firefox 2.0.0.12: 52/100
• Camino 1.5.5: 53/100
• SeaMonkey 1.1.8: 53/100
• IE 6: 11/100
• IE 7: 12/100
• IE 8 Beta: 18/100
• Opera 9.26: 46/100.
• OmniWeb 5.6: 40/100

For the sake of full disclosure, I’m running Mac OS X, version 10.5.2. Versions of IE browsers were run in a VMware Fusion virtual machine.