Article
About the Author
James Edwards
James (aka brothercake) is a front-end developer based in the UK, specializing in advanced JavaScript programming and accessible web site development. He is an outspoken advocate of standards-based development, and contributing author to SitePoint's The Art & Science of JavaScript.
HTML or XHTML: Does it Really Matter?
I could say that HTML has come a long way since its first standard specification, HTML 2.0, was published in 1995. I would like to say that—but it wouldn’t be true.
It only took another four years for the next specification to be published—HTML 4.01, in 1999—and here we are, eight years later, with no significant advances having been made since then.
But maybe that’s a good thing. Maybe the stability of HTML 4 is a testament to its design (here at SitePoint we just released The Ultimate HTML Reference today in print form. Print!) Or perhaps it can be perceived as stagnation, which points to something far trickier …
See, back in the day when the Web was new, unexplored, and used primarily by academics and über-geeks, it must have been far easier to reach consensus on how things should be. Few people were involved, and even fewer of them had any specific vested interests. But now the Web is established, relied upon by millions of people. The fortunes of corporations large and small rest upon it. And now that so many people have strong and specific opinions and agendas, it becomes almost impossible to agree on what the standard should be.
I think that’s why the development of HTML (and, for that matter, CSS) has stalled so dramatically.
But with the advent of HTML 5, change is in the air. This change is not without controversy, but it is welcome change nonetheless. Later in this article we’ll take a dip into the draft specification to see what we can expect from it, but first I’d like to look backwards at a little of the history and development of HTML.
<i> ♥ <html>
HTML was originally conceived as a semantic language, in which elements should describe only the meaning of their content, not the presentation. However, this good intention didn’t hold up very long.
HTML 3.0 was proposed and drafted in 1995, but included many new elements—such as support for mathematical figures—which were considered by browser vendors to be too complex to implement. Vendors chose to implement only part of the proposal, and also to add new markup (predominantly presentational markup) that they thought should be included, in the hope that this would be subsequently ratified by the W3C.
As it turned out, much of this new markup was indeed adopted. HTML 3.2 was finally published as a specification in 1997, and standardized many of the new presentational elements and attributes, such as <font>, <center>, and align, which had already been implemented by browsers.
In 1997, the HTML 4.0 specification was published, and although it continued to include presentational markup that had been instigated directly by vendors, it also began a push to clean up HTML, calling some markup “deprecated” and suggesting that it not be used. The HTML 4 standard came in three flavors:
- strict—no deprecated markup allowed
- transitional or loose—deprecated markup is allowed
- frameset—predominantly frame-related markup is allowed
But the horse had bolted, leaving the stable door swinging uselessly on its hinges. By this time the W3C had already lost control. The Web was exploding, and different browsers—primarily Netscape Navigator and Microsoft Internet Explorer—were competing over proprietary features and implementations (remember <layer>?). This period is often referred to as the “browser wars.”
Whither XHTML?
XHTML 1.0 came along in 2000 as formalization of HTML 4 into XML. XML itself had been standardized in 1998 as a general specification for defining markup languages, and was a stricter and simpler offshoot of SGML, the Standard Generalized Markup Language from which HTML itself was originally derived.
XHTML was initially very well received; it was the newest standard, and was perceived to better address the post-war push for standards and accessibility. Indeed, the first version of the Web Content Accessibility Guidelines implied the use of XHTML in its point 11.2: “Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported …” (my emphasis).
Despite this honeymoon, however, the latent issues of XHTML soon began to appear. The vast majority of developers using XHTML were serving it with a text/html MIME type, which meant it was parsed by browsers as regular HTML rather than XML. To an HTML parser, an XHTML self-closing element (such as <img/>) is just an element with an extraneous character (<img>>). Therefore, its successful use relies on error handling—which is what makes it backwardly compatible.
However, problems arise when XHTML is served as XML, using the application/xhtml+xml MIME type or similar. The first of these is that the dominant web browser, Internet Explorer, doesn’t support that MIME type; for such documents it will prompt for download rather than attempting to display them. And in browsers that do support the MIME type, 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, as this example from Firefox shows.
In usability terms this is clearly unacceptable, as the vast majority of users will have no idea what it all means or what to do about it. Even hard-core XHTML advocates like myself were nervous about serving it as XML on their own sites, and wouldn’t even consider it for client sites.
So if real XHTML is too finicky to use, and XHTML served as text is just HTML with syntax errors and none of the benefits of XML (such as being able to embed other forms of XML, and to use namespaces), what’s the point of XHTML at all? Why not just stick with good ol’ HTML? After all, the strictness and emphasis on semantics that we find in XHTML is equally present in HTML Strict. If strictness means something to you, HTML can deliver!
These are essentially the arguments made by Ian Hickson in his iconic article, “Sending XHTML as text/html Considered Harmful”. It’s my perception that this article was the linchpin of the anti-XHTML movement. I also disagree with Hickson’s arguments in every important respect.
XHTML is still worth using, because it’s a transitional standard that moves us towards a pure-XML Web. XML is inherently better than SGML, because it’s simpler and stricter, and much easier to parse (once you’ve understood its rules). I don’t know from where we’ve adopted the idea that we should be forgiving of markup errors, but I don’t share that view.
Only the validation-error issue is a major bugbear in my book. Some browsers are working to improve the situation—Opera, for example, will show validation errors, but will still attempt to parse and display the page. And anyway, it’s not that hard to make solid pages that will reliably display correctly, even when considering user-generated content—you just have to be careful.
But more pertinently, XHTML can still offer the benefits of XML to some browsers, even if others don’t benefit. A good example of this is a script I wrote a while ago that replaces text with embedded SVG (similar to SiFR). Of course, it only worked in browsers that supported embedding SVG when the page is real XML. But at least it failed cleanly in other environments, leaving the original text untouched.
So we have a situation where the document must be XML if it can be, but it doesn’t really matter if it isn’t. This, I think, is a clear case where it’s worth content-negotiating and serving XHTML as XML to supporting browsers.