innerHTML

I have what a former professor of mine called fear of the “fraud squad.” Today’s example: if someone looking at my CSS asked me to articulate the difference between a and a with the :link pseudo-class, i.e., a:link, could I explain the difference? Or would I throw out a useless definition and then hear the fraud squad busting through my office windows from their black helicopters?

I couldn’t articulate the difference but can now. The venerable W3C states that browsers use :link and :visited to distinguish between links that have not or have been visited. Also, these pseudo-classes are mutually exclusive. So, what’s true for a:link will never be true for a:visited, and vice versa, but if you define a style for a, it will be true for both.

About pseudo-classes: a layman’s definition of a pseudo-class is hard to find, but 456 Berea Street has a blog entry on pseudo-classes that’s helpful.

I was pleased to see that whitehouse.gov passes W3C XHTML validation and uses jQuery.

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.

I posted this question to Ask Metafilter. I’m befuddled. It’s not a major befuddlement, but a minor curiosity.