Most people use HTML V4 and XHTML V1 to create Web pages. Relatively few HTML enthusiasts understand the concepts of semantic HTML, validating HTML structures, and improving documents for accessibility. A high-quality HTML document is a result of many trade-offs, design choices, and discussions. Despite all criticism, no alternative even nearly as universal as HTML exists. Most users settle for the standard as it is, even if it will be the final version ever produced.
Like any other standard, however, HTML will have successors. Even now, specialists are thinking about the next version of HTML, solving every known issue in the current version. And like any group of people, these specialists disagree on the future direction of this work.
The first proposal for a new HTML version came from a work group initiated by the W3C. This group's idea centered around XHTML V2—a standard that continued previous developments in XHTML toward a purer version and returned to the design philosophy of the first editions of HTML.
Some prominent HTML specialists outside the W3C—browser vendors, Web developers, authors, and other stakeholders—disagreed with the direction of XHTML V2. In 2004, they started an independent work group to propose an alternative direction for the next version of HTML. Under the flag of WHATWG (Web Hypertext Application Technology Working Group), the group put together proposals for HTML V5 and Web Forms V2.
After a few years, the working draft is a clear description of an alternative direction for HTML. In April 2007, the W3C voted on a proposal to adopt HTML V5 for review, without accepting it as an official recommendation (yet). A great majority voted in its favor. As a result, an interesting situation has arisen: The W3C is working on two competing successors for HTML and XHTML. In theory, both proposals have legitimate justifications. In practice, many hurdles must be overcome before the all the major browsers support the standards.
Those are the dry facts leading to the current situation. The more interesting discussion surrounds the actual disagreements between the two proposals. This article describes the essence of each proposal from a bird's-eye view, then looks at the details of either philosophy.
A brief history of XHTML
Before you can understand the philosophy behind XHTML V2, you need a bit of history. In the early 1990s, the first version of HTML was based on Standard Generalized Markup Language (SGML). The key difference was the hyperlink feature—the key foundation and success factor for the World Wide Web. Like SGML, HTML allowed authors to describe the structure of a document, separating headers from paragraphs, ordered and unordered lists. The appearance on screen was browser dependent.
With the increasing popularity of the Web, HTML users demanded control over the look and feel of their pages. Browser vendors pushed new features into HTML V2 and V3. Web pages degenerated into inaccessible, complex structures of nested tables as the primary way to control page layout. The rest of the document was filled with font tags and color declarations. Original document structures could not be recognized.
HTML V4 was designed to end this chaos, as it externalized presentation logic to CSS and
introduced layers (
DIVs) for advanced positioning of
content. This meant a paradigm shift compared to HTML V3. To simplify the migration,
a Transitional version of HTML V4 supported the old HTML V3 constructs. The Strict
version enforced full separation of content and presentation for advanced HTML
The first HTML V4 sites adopted
DIVs as the new holy
grail and used them for almost every element in a page that needed a little
decoration, including (but not limited to) page headers. The style attributes in
HTML were a popular placeholder for presentation details. In the end, superfluous
tables were eliminated from the page. But content and presentation logic were still
mixed throughout. The obligatory CSS file consisted of just a few lines.
More recently, some well-known Web developers started to promote the more elegant
approach of HTML V4 with style sheets. In modern browsers, CSS properties
aren't limited to
DIV elements. You can style all HTML
elements any way you like. Many weblogs started to talk about semantic HTML.
Without completely banning the
DIV element, authors
try to use HTML elements that best described the content they contain. For
example, the navigation menus you find on most Web sites can best be described
as unordered lists. Also, instead of using a class named
bigHeader on a paragraph element, they prefer the
H1 element, using CSS to change its appearance as
In the meantime, the W3C proposed XHTML V1 as an equivalent to HTML V4 rewritten as well-formed and valid XML. For XML users, this simplified the task of transforming XML content to Web pages and validating the result with existing validators. XHTML V1.1 is an effort to separate concerns into separate modules. The modular approach makes it easier to reuse parts of the standard for different purposes and to extend the standards with new features.
Even more than HTML V4 users, XHTML V1.1 users separate content and presentation. As always, however, some practical requirements can only be solved by using dirty tricks in CSS. For example, the menu structures described as unordered lists usually consist of good-looking images. Images, however, are not easily read by text-to-speech devices for people with visual disabilities. Also, text browsers such as Lynx don't present images well. A dirty CSS trick allows you to hide the text and show a picture in the browser. But if the content of the menu is different from page to page, it's not very elegant to specify this content in a CSS.
The philosophy behind XHTML V2
The first and most important design philosophy behind XHTML V2 is to further improve
the separation between content and presentation, improving the remaining flaws from
HTML V4 and XHTML V1. For example, native support to specify an image
source for each item in an unordered list. The old
tag is replaced by the option to specify an
SRC on any
element. With this change, the CSS is free of content, and alternative devices can
easily present the text instead of the image.
Within the modular approach, XHTML V2 replaces HTML Forms with the XForms module, adding support for common concerns by using appropriate application models. In XForms, you can specify interactive logic, validation rules, and computations without a single line of script. Also, the technique uses rich XML structures instead of key-value pairs, allowing nested sub-forms and repeating elements. Besides offering a powerful engine, text-to-speech devices are better able to translate the full richness of the application.
In addition to XForms, several other concerns from the XHTML definition are extracted into stand-alone specifications that can be reused for other purposes—for example, XML Events, XFrames, and Ruby (for Asian languages).
Along with the separation of presentation, programmability is also separated
from the standard. Interaction attributes such as
are replaced by the XML Events module. Because the XML Events specification is
natively designed for this purpose, it offers a more powerful set of tools to
handle user interaction.
To summarize the innovations in XHTML V2, the main philosophy is the separation of concerns. Each concern is no longer a secondary feature of HTML but a primary goal for a new specification. As a result, the new specifications are better optimized in the interest of the issue at hand. However, separation of concerns is a philosophical goal rather than a practical one. A clever developer who has the technical skills to use the full set of tools appropriately can achieve effective results. It is questionable whether average users of current HTML versions are capable of creating XHTML documents of proper quality.
Most likely, XHTML V2 isn't aimed at average HTML authors. But in the hands of the right developer, it leads to very elegant solutions fully optimized for accessibility.
The philosophy behind HTML V5
The WHATWG is taking a far more practical approach in designing HTML V5. Instead of chasing an abstract ideal such as separation of concerns, the group started to document the current actual behavior of major browsers, which is different from the W3C specification. Using this analysis as a foundation, the group investigated how HTML is actually used in practice.
With this information, the group began to propose features that might simplify the lives of average Web developers. Although HTML V5 respects its origins from former versions of HTML, purification is not a primary goal. For example, the primary purpose of modeling documents is easily replaced with optimizing for Web applications.
Development of Web applications is greatly simplified with a modeling language that
has native support for this purpose. For example, HTML V5 has native support for
interactive components such as data grids, menus, and toolbars. Using descriptive
to simulate the behavior with general-purpose
HTML V5 is more similar to HTML V4 than XHTML V2 is to XHTML V1. The migration path is smoother, and it's easier for an experienced HTML V4 developer to become accustomed to the new version. New features follow the similar logic. Specific event attributes for specific elements allow HTML editors to provide more appropriate text completion.
The main philosophy behind HTML V5 is to extend HTML V4 with practical features that the average Web developer requires. HTML V5 simplifies the technology as it continues the familiar approach from HTML V4. To address flaws from HTML V4, HTML V5 prefers a minimal approach over a major redesign.
Practical use of the new standards
XHTML V2 and related modules are officially supported by the W3C, and the related modules are becoming key ingredients for other XML specifications that the W3C maintains. Unfortunately, official W3C approval is no guarantee of support by major Web browsers. Supporting plain, vanilla XHTML V2 isn't the issue: Modern browsers already support many features. Proper use of XHTML V2 depends on the availability of the related modules. At the time of writing, it's unclear whether Microsoft will extend Windows® Internet Explorer® with capabilities such as XML Events and XForms. A Mozilla XForms plug-in, including XML Events, has been under development for a few years now. The plug-in proves both the capabilities of the technology and the difficulties in the implementation.
The HTML V5 specification was written using good communication with browser vendors, keeping implementation concerns in mind. The team is sceptical about official W3C approval, though. The FAQ doesn't even try to give a serious answer about the expected date of approval. Regardless of the W3C, browser vendors might decide to implement an unofficial HTML V5 standard anyway. It wouldn't be the first time browser vendors were ahead of official recommendations.
At this point, neither HTML V5 nor XHTML V2 are official recommendations yet. Some details might change in future. What doesn't change is the direction they take, each addressing a different set of flaws in the current standards. It will be interesting to see how future browsers will add support for each new standard. Current browsers support both HTML V4 and XHTML V1. Similarly, future browsers might support both HTML V5 and XHTML V2. The standards will appeal to different audiences.
If you're more interested in XHTML V1.1 than HTML V4, looking for an elegant approach to create documents accessible from multiple devices, you are likely to appreciate the advantages of XHTML V2. If you only use XHTML V1 because of its XML compliance but you prefer the new features in HTML V5, you might appreciate XHTML V5 (HTML V5 rewritten as an XML dialect).
HTML V5 is best appreciated by developers of interactive Web applications using HTML V4. It should also be the more practical alternative for sites maintained using What You See Is What You Get document editors. Considering the situation, though, HTML V4 and XHTML V1 are likely to stay around for a long time.
- XHTML V2: Read the W3C working draft.
- HTML V5: Read the W3C editor's draft and the WHATWG working draft.
- developerWorks XML zone: Learn all about XML at the developerWorks XML zone.
- IBM XML certification: Find out how you can become an IBM-Certified Developer in XML and related technologies.
- XML technical library: See the developerWorks XML Zone for a wide range of technical articles and tips, tutorials, standards, and IBM Redbooks.
- developerWorks technical events and webcasts: Stay current with technology in these sessions.
- The technology bookstore: Browse for books on these and other technical topics.
- Participate in the discussion forum.
- XML zone discussion forums: Participate in any of several XML-centered forums.
- developerWorks blogs: Check out these blogs and get involved in the developerWorks community.
Dig deeper into XML on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.