HTML vs. XHTML: The Five Key Takeaways

The Web continues to evolve and so must its lingua franca. From the need to support routine to specialized renderings (e.g., mathematics) on a wide variety of devices, to Web 2.0 plus emerging Web 3.0 applications, there are numerous drivers demanding evolution. Ultimately, the issue with HTML is that it smears the distinction between presentation (i.e., the display of rendered markup in a Web browser on a specific device) and structure (i.e., the contextual organization of the content being communicated). And despite the fact that HTML has undergone a number of revisions, attempts to separate presentation from structure have been available as options.

To address the requirement for separating presentation from structure, HTML is being systematically XMLified. In other words, using a phased approach, HTML is becoming increasingly XML-like. Increasingly then, XML will become the lingua franca of the Web. Given that XML has already seen significant utility and uptake, it is definitely more a question of when, rather than if this XMLification will take place.

Traditionally, Web pages have been rendered in Web browsers by very forgiving HTML interpreters. These interpreters are known to make best-effort attempts even when the HTML in evidence departs significantly from the standards. With XHTML, that free lunch is over, as XHTML places strict demands on markup syntax:

• XHTML is case sensitive - e.g., XHTML elements must appear in lower case.
• XHTML requires explicit indication of the end of an element. This means, for example, that paragraph tags have to have a begining <p> and end </p>. And that is understandable as it delineates a structural aspect of a document. However this rule also implies that, for example, the HTML break tag, <br>, becomes <br /> - which is somewhat less intuitive ...
• Nested elements are allowed in XHTML, but they must be well-formed. In other words, elements must not overlap each other as in <b><li>A list item</b></li>. (HTML silently forgave such indiscretions ...)
• XHTML element attributes must be quote-delimited - e.g., in <img src="image.gif" alt="some text" width="32" height="32"> the image width and height attributes must be enclosed in quotes.
• XHTML requires use of character entity references. In other words, if there is a need for an ampersand in the text, "Smith & Associates" becomes "Smith &amp; Associates".

Although this laundry list captures most of the common differences between HTML and XHTML, there may be others - especially as XHTML continues to evolve.

All of the above points to the increasing importance of compliance with XHTML. Unfortunately, XHTML is a bit of a moving target at the present time - e.g., XHTML 1.0 is based on a reformulation of HTML 4, but XHTML 2.0 is in-the-works. Add to this the fact that different flavors of XHTML exist - e.g., in XHTML 1.0, strict, transitional and frameset flavors are available. Regardless of the XHTML flavor, validators serve as the authoritative checkpoints regarding compliance.

Again, all of the above suggests that conversion to XHTML is required. This is not something that needs to happen overnight. However, organizations would be prudent to develop plans for such migrations. And although various tools exist to automate the migration from HTML to XHTML, all of the above also suggests that some of this effort may require manual intervention ... In the case of net-new content, however, organizations would be wise to insist on use of XHTML from the outset.

Short-term pain for long-term gain might be how some perceive the necessity for XHTML. And although one might argue for different perspectives, there is little doubt that the means (XHTML) will justify the end (a systematically improved Web).