HTML v 4.01 kept pace with the dizzying developments in Information Technology (IT), and provided for additional support of stylesheets, enhancements to tables and interactive forms, expanded scripting capabilities, and increased support for multimedia. There was always a drive to keep up to the market demands, and never really an opportunity to get ahead of the game. The driving forces of HTML and its various enhancements could be typed as dynamism and interactivity. These twins underlie the very rapid incorporation of scripts, forms, frames, and objects into the HTML platform. However, some would complain that these developments hindered the broader acceptance of HTML. Developers who had just mastered one iteration of the language would complain because the rapid acceptance of these extensions made the language too cumbersome and ‘‘needlessly complex.’’

There was also the problem that bedeviled every earlier version: cross-platform compatibility. Not all browsers could support a common set of features, and sometimes had competing features so that a lot of the benefits of 4.01 went untapped. As usual, any Web page to get to the broadest user audience had to be backward compatible, and designers had to either design for multiple browsers (and even different versions of them) or design for the lowest common denominator, HTML 2.0.

The Arrival of XHTML

The solution was a newer version of HTML. Thus, HTML 4.02 and XHTML 1.0 co-emerged in 2001, combining the strengths of HTML 4.01 with the special benefits of Extensible Markup Language (XML) with the aim of creating a language that worked on a broad range of browser platforms and was also simpler to design with. One of the apparent advantages of XHTML was now the capability to define and manipulate the types of content expressed within a Web page. This meant you could now reach into a block of data containing information about a date and make changes to one of the elements of the date object, such as the year or day or month. XHTML also was more rigorous than any previous version of HTML in that all tags and attributes had to adhere to one of the following three XML document type definitions (DTDs) to be considered a well-formed executable document:

- Strict As its name certainly implies, this DTD is strict. It does not allow any deprecated elements or attributes and does not support frames.

- Transitional This is the very forgiving one. It accepts deprecated elements and attributes. It is for the old hands among us who are quite comfortable with HTML and who are willing to try something new, but not if it’s going to be that difficult.

- Frameset This is used for Web pages designed for frames.

Needless to say, XHTML is not supported among all browser types, though all modern browsers support XHTML to some extent. Firefox 2 and IE7 are XHTML-friendly. However, Microsoft’s own validators inside the Visual Studio IDE validate against XHTML. XHTML 2.0 came out in 2004 and was designed to transform into a Web design language that has left behind most of the presentational elements of HTML. Its current use in the Web design community is not extensive.

Even in 2007, with XHTML 2.0 designed for Web design, the implementation that developers can be certain almost all browsers would support is only HTML 2.0, which, again, was codified more than a dozen years ago.

For fun, just to see how close we (as Web developers) are to conforming to the new (and upcoming) standards that have been so hyped as the cure-all for staid limitations of HTML, we used the code checker validator.w3.org/check/referrer on a pretty good site: http://www.google.com. It came up with 178 noncompliance issues with the newest version of XHTML and, if you take a look at the source code, it’s pretty standard HTML 4.01.

Now, even with the issue of backward compatibility when designing for the future, you simply come to the issue of need. Despite all the hyperbole regarding the advantages of XHTML, it just isn’t happening in real life. This isn’t to say that XHTML won’t eventually supplant HTML, but history in the industry is against it.

Networking still uses TCP/IP, Unix is the foundation of Mac OSX, and millions upon millions of Web pages have been created using HTML. In other words, HTML in any form won’t be going away, and any improvements to it will not be coming from a standards-making body. Rather, they will come about the way HTML has always improved: via a codification of existing practice.