HTML5, XHTML2, and the Future of the Web
Published on April 10, 2007
As workers on the web today, we are dealing with many technologies that have been stable for a long time.
HTML 4.01 was made a recommendation in 1999, XHTML 1.0—a formulation of HTML 4.01 in XML—became a recommendation in 2000, and was revised in 2002. In other words, at the base of all modern web development is an eight-year-old technology.
HTML 4.01 may be a good, stable ground for developers to stand on, but it could be better. Lots of things have changed in the way the web is used and perceived in the last eight years, but particularly from a developer perspective, we’ve gained an understanding of what HTML 4.01 failed at, and where it could be improved. The next generation of these technologies is arriving, and they are worth keeping an eye on. These technologies will affect everyone in the business.
The W3C has long had XHTML2 in the works, a technology that aims to fill the same role as HTML 4.01 and XHTML 1.0, an upgrade or replacement with many improvements and changes to the semantic elements available. XHTML2 is XML—just as XHTML 1.0 is—but it doesn’t have backward compatibility to HTML 4.01. It can, in fact, be considered an entirely new language, something made very clear by the fact it has a completely different namespace.
HTML5 (also sometimes referred to as Web Applications 1.0) is a technology developed by the WHATWG, an open community started by three of the four major browser vendors: Mozilla, Opera, and Apple. HTML5 is not so much a replacement for HTML 4.01 or XHTML 1.0 as it is an upgrade or evolution. It aims for backwards compatibility, tries to remove undefined behavior in HTML 4.01 by defining it, and looks at the various browsers’ tag-soup parsing behavior to try to define the best solution that doesn’t break the web. At the same time, it adds sorely needed semantic elements for things such as improved form validation, interactive elements, and persistent storage.
HTML on the Web Today
While HTML 4.01 is formally an SGML-based document format, the only clients actually treating HTML that way are validators. Browsers, on the other hand, treat HTML documents as tag soup—they try to make sense out of, and display, even the most horridly broken document to their best ability. Very little content on the web is valid HTML 4.01; most of it is invalid and ill-formed, but browsers still have to parse it, or they will soon be disregarded as users switch to browsers that support their favorite sites.
Tag-soup handling—trying to correct errors in documents—is essential, but every browser does it a little differently. All browsers try to get as close as possible to how their largest competitors do it, but even when broken content works the same in different browsers, it doesn’t necessarily mean that they are performing error correction in the same way, just the way that both works for the common case and is most practical for them. HTML5 tries to put an end to this need for reverse engineering of competing browsers by defining exactly how this error correction is to be done. HTML5 doesn’t just define how valid documents are to be parsed, it also defines how parsing should work if documents are invalid, ill-formed, and broken, so that browser vendors can make their products fully interoperable with each other.
XML on the Web Today
The vast majority of all XHTML on the web is served with a content type of “text/html”—in other words, it is parsed as tag soup by browsers, not as XML.
Among the reasons for this is the draconian error handling of XML. XML parsing will stop at the first error in the document, and that means that any errors will render a page totally unreachable. A document with an XML well formedness error will only display details of the error, but no content. On pages where some of the content is out of the control of XML tools with well-designed handling of different character encodings—where users may comment or post, or where content may come from the outside in the form of trackbacks, ad services, or widgets, for example—there’s always a risk of a well-formedness error. Tag-soup parsing browsers will do their best to display a page, in spite of any errors, but when XML parsing any error, no matter how small, may render your page completely useless.
The biggest problem with serving documents as XML on the web is that Internet Explorer doesn’t support the recommended XHTML 1.0 content type (“application/xhtml+xml”). It does support generic XML, but without any knowledge of the XHTML namespace, it has no knowledge of the semantics of any XHTML elements, and won’t even apply the /files/includes/default.css browser style sheet. (It is possible to apply XSLT to transform the document to HTML tag soup, but since the DOM is different for XML mode compared to tag-soup mode, this means scripts working in one mode may be completely broken in the other mode.)
XHTML 1.0 does allow serving documents as “text/html” though, given that they conform to the backwards compatibility rules of Appendix C of the HTML specification, but—of course—this means that the documents will be treated as tag soup, and is effectively not XML on the web. (The possibility to serve a document as tag soup just to browsers not supporting XHTML as XML exists, with the same caveat as when transforming them using client side XSLT, and more added from differences in character-encoding handing.)
The fact that Internet Explorer doesn’t really support XHTML as XML in any way, and the problems XML can cause when not all tools in the authoring chain are XML tools, means that there has been little incentive for using XML on the web. This is compounded by search engines not indexing XHTML as XML documents; very few XHTML authoring tools for XML; very few CMS or blogging tools supporting XML correctly all the way from input through database to generation; and very few ad suppliers supporting XML.
There is a little incentive if you want to allow MathML, SVG, and other XML applications to be interspersed inline in XHTML documents, but this use of XHTML as XML has found a very limited audience.
XHTML2 is XML
And therein lies the biggest problem. On top of all the concerns that web developers have about using XML for serving documents, XHTML2 adds another layer of complexity. It isn’t HTML 4.01 reformulated as XML; it’s a different but similar language, with added, removed, or modified semantics for many elements, and added or changed element vocabulary for many semantics. In many cases, the changes are steps in the right direction, but at the same time, XHTML2 was not built with web developers in mind. As an example, it doesn’t at all address the deficiencies of HTML 4.01 and XHTML 1.0 in the areas of interactivity, local storage, or script interactions.
XHTML2 is a working draft at the moment. While parts of it have been as they are for years, in general it’s not stable enough to author documents to, it’s not quite ready for implementation, and it lacks support from four very crucial directions: browsers, search engines, content-management systems, and authoring tools. None of the major browser vendors supports XHTML2, and Apple’s Maciej Stachowiak even went so far as stating:
We declined to participate in the XHTML2 Working Group because we think XHTML2 is not an appropriate technology for the web.
Web Applications 1.0 is More than HTML5
The Web Applications 1.0 (WA1) specification updates HTML, but that’s not all it does. It also updates XHTML 1.0 (under the unfortunate and confusing name of XHTML5), and the HTML DOM under the name of DOM5 HTML. While HTML 4.01 is formally SGML-based, HTML5 accepts the reality of all browsers using error-correcting tag-soup parsers, and instead describes a specific non-SGML parsing model that includes a defined error correction model. (XHTML5 is still parsed by an XML parser, and parsing is covered by the rules of XML and not HTML5.)
WA1 also defines several application programming interfaces (APIs) that have been de facto standards, and adds new ones. Where XHTML2 enhances XHTML as a document description language with improved semantics, WA1 does a more modest enhancement to document semantics but also improves on the abilities to use the web as an application platform by adding things such as document state storage in the browser history, local data storage, offline browsing, drag and drop, copy and paste, undo and redo history, cross document messaging, and more.
Unlike XHTML2, which doesn’t have any support from browser vendors, HTML5 has support from all the major browser vendors except Microsoft. The specification is not finished yet, but different parts of it are at different levels of maturity—many parts are already implemented in browsers, for example, the canvas element, which is supported by Mozilla, Safari, and Opera browsers, has been used in many demonstrations of advanced functionality.
W3C and HTML
The W3C has recently chartered a new HTML Working Group, separate from the working group that is chartered to produce XHTML2. The HTML Working Group is open to the public through the mechanism for becoming an invited expert. How it ties in with work from the other W3C working groups—as well as with the WHATWG —remains to be seen. The chairs of the new group are Chris Wilson, Platform Architect of the Internet Explorer Platform team at Microsoft, and Dan Connolly of the W3C.
The W3C has already adopted a lot of WHATWG technologies through the Rich Web Clients Activity, aiming at improving the client side experience of the web. The new HTML working group has a dependency on at least one of the working groups in that activity, the WebAPI working group. The scope, deliverables, and relationship to external groups part of the HTML working group charter makes it a reasonable assumption that the new HTML working group will try to use the HTML5 specification, or at least a lot of the work the WHATWG has put into HTML5, as the ground for the updated HTML and XHTML specifications it is chartered to deliver.
Suitability for Web Developers
Browser support is always a crucial point for web developers. Internet Explorer doesn’t have proper XHTML support at all, and it has severe problems with XHTML sent as XML—character encodings handling, externally provided content, and the handling of content as strings instead of guaranteed well-formed XML makes XML tricky even if you get over that hurdle. Turning an HTML 4.01 or XHTML 1.0 document into XHTML2 isn’t necessarily straightforward—there are changes to the structure of the document that will be required, and, crucially, none of the major browser vendors supports XHTML2.
Turning an HTML 4.01 document into HTML5, on the other hand, is in most cases just a question of replacing the
While XHTML2 is a semantic improvement over XHTML 1.0, it does not seem likely that it will matter for web developers for a long time, especially when one considers that Internet Explorer still doesn’t offer XHTML 1.0 support. It will take many years for a new version that might support XHTML2—and we have been given no indication that the next one will.
On the other hand, many parts of HTML5 are already creeping into browsers, and, if Microsoft takes an active part in the development of HTML5 in the future, it looks likely that many features that are already very polished will be supported cross-browser in a much shorter timeframe. The fact that HTML5 contains several areas that are already ready for implementation while still being developed in other areas makes it a technology that is easy to partially adapt until browser support is fully evolved for the features you wish to use.
HTML5 will be the future of the web, so my advice would be to pay close attention to it.
- Tim Berners-Lee: Reinventing HTML, on the decision to create a new HTML WG