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.
Arise HTML 5?
One of the primary aims of HTML 5 is to define how exceptions should be handled, so that malformed or invalid markup will be treated in a predictable way. Unlike previous version of HTML, the specification is anchored firmly in real-world implementations, based as it is on observation of content and implementations that are already out there, and will not be considered final until there are at least two interoperable implementations.
HTML 5 syntax is compatible with both HTML 4 and XHTML 1. HTML 5 documents that use HTML 4 syntax must be served as text/html, while those that use XHTML syntax must be served as XML. The DOCTYPE has also been greatly simplified, and is used only to switch a browser into standards mode (rather than to refer to a DTD); the DOCTYPE is not required for XML documents, which are always rendered in standards mode.
And, perhaps most significantly for authors, the specification adds a whole new raft of elements, attributes, and scriptable APIs. These include:
- new structural content elements, such as
<article>,<section>,<header>, and<footer> - new embedding elements, such as
<figure>,<audio>, and<video> - new semantics for common data structures, such as
<time>and<datagrid> - elements designed specifically for building web applications, such as
<output>(for the output of a scripted process),<progress>(for showing the progress of a long process), and<event-source>(used for handling server-sent events), as well as a range of new<input>types, such asdatetime,range,email, andurl - a range of new scripting methods for addressing documents and embedded content, such as a 2D-drawing API for the
<canvas>element, a drag-and-drop API for thedraggableattribute, and additional DOM methods likegetElementsByClassName()andgetSelection()
However, along with these additions are a number of controversial removals, many of which are concerned with accessibility features – think of the alt attribute of <img>, and the summary and headers attributes of <table> markup. The main rationale for removing these is that in practice they are barely used, or barely used correctly. I contend that this isn’t a good enough reason – these are valuable and necessary accessibility features, and removing them without a specific good reason is not okay. Sure, it’s a shame that these attributes are so seldom used correctly, but rather than removing them, it provides a reason for better educating developers on their correct use.
NOTE:
Within the HTML 5 working group, the discussions about this seem to be mostly focused around the needs of authoring tools. But frankly, I don’t see why we should care about their needs. Those who’ve shown a determination to work to standards don’t need to be persuaded about their value; those that haven’t are not going to be persuaded now. The commercial agendas of individual companies should not in any way inform the standards-making process.
Conversely, some presentational elements and attributes have been retained because they’re so commonly used in practice, effectively sanctioning the use of non-semantic markup. These include <hr>, <b>, and <small>. Yet at the same time, other elements such as <big> and <center> have been removed on the basis that they’re purely presentational. I’m not sure how this distinction was arrived at other than by reference to popular usage, but it’s bogus in my view. When defining a specification, we should consider the usefulness and relevance of a particular piece of markup – not ratify the incorrect ways in which people are already using it.
The situation for <table> markup is especially disappointing. Since the headers attribute has been removed, there’s no longer any way to describe the internal structure of a complex table for assistive technologies, where scope isn’t enough. Many developers have written about this issue, most notably Gez Lemon.
The specification aims to provide a “focus on accessibility as a built-in concept for new features,” which implies a desire to have accessibility baked in. But how does removing accessibility features – and not replacing them with alternatives – achieve that aim? HTML 5 does not have accessibility baked in; it barely considers it as an afterthought, because its true emphasis is on providing semantics for visual web application interfaces, rather than structured and mode-independent documents.
In many ways HTML 5 is an exciting development, as it offers a huge and comprehensive range of new semantics and APIs. This has to be a good thing – we’ve outgrown HTML 4 and it’s no longer fit for our purposes. However, the lack of serious focus on accessibility, the over-emphasis on the needs of authoring tools and RPC applications, and the excessively pragmatic attempt to sanction existing bad practices are all causes for concern.
But what is particularly interesting, I think, is how HTML 5 came about in the first place. The W3C didn’t initiate it; rather, it was drafted and developed by an independent group called WHATWG (Web Hypertext Application Technology Working Group) and only later embraced by the W3C.
I find it extremely pertinent to note how such a major development was beyond the vision of the W3C and had to be kicked into life independently. We saw the same situation with microformats, and both of these instances suggest the W3C has grown incapable of innovating. This stagnation is possibly a facet of its excessive bureaucracy – a tendency for all large and established organizations.
Avast XHTML 2?
It seems unlikely that XHTML 2 will gain serious traction. It is implementations that make or break a technology – and nobody (not even Mozilla) seems interested in implementing XHTML 2.
There are some good ideas behind XHTML 2 – particularly, in my view, the ability for any element to take a src attribute – but it’s insanely complicated, and requires absolutely that its documents be served as XML. XHTML 2 isn’t designed to be backwardly compatible, and although that sits well in an academic sense, it’s a minefield of problems in the real world. Just one problem is that site owners would have to perform live transforms of XHTML 2 into XHTML 1 during the transitional period.
But here’s the thing: XHTML 1 was supposed to be that transitional period! Yet without ubiquitous uptake we can never move beyond it, so it appears to be highly unlikely we ever will. XHTML 2 is still a Working Draft, and will probably never progress – what’s the point?
Conclusion
This article has sought to show that the move back from XHTML 1 to HTML 4 was a retrograde step. I’ve demonstrated how there is value in using XHTML, even if only some browsers can truly benefit from it, and this continues to underpin my belief that XHTML is better than HTML 4.
I have my concerns about HTML 5, but am nonetheless impressed and excited by the innovation. I look forward to a time when we can actually use it, which for me means that the specification is stable and all major browsers implement the larger part of it. But long before that time can come about, HTML 5 needs to offer a decent level of accessibility markup, which currently it does not. If the issues enumerated earlier are not resolved, I may consider ignoring HTML 5 and sticking with XHTML 1.
Either way, I will continue to use XHTML syntax and reap the benefits of XML wherever possible. And that’s my advice to you.
James EdwardsJames is a freelance web developer based in the UK, specialising in JavaScript application development and building accessible websites. With more than a decade's professional experience, he is a published author, a frequent blogger and speaker, and an outspoken advocate of standards-based development.
