Ed Dumbill is no longer the editor for the XML.com journal, but he's still a columnist and is always an interesting source of news and opinion. His July 28 XML Deviant column includes a fascinating discussion about XHTML, the reworked version of HTML that incorporates XML syntax and well-formedness requirements, while keeping most of the markup from HTML more or less intact. He presents a pro and con on XHTML that (if you'll allow me to paraphrase his reports and remarks) contrasts the wishes of XML purists who'd like to see Web browsers pick up and run with the rigor and power of pure XML, and Web pragmatists who recognize that a syntactically regular, cleaned-up version of HTML is easier to process than its predecessor. There's some virtue in both viewpoints depending on what you want to do with markup, and whether or not it's intended for viewing inside a Web browser or in the context of some other application.
This got me to thinking about my own checkered history with XHTML. I got caught up in the early optimism and heady times in the late 1990s when XHTML promised to fix everything that was wrong with HTML. In retrospect, I wonder how could we have believed a change in syntax would wipe the slate clean on what was then and is still now an "interesting" (in the sense of the Chinese curse) collection of browser specific extensions, rendering capabilities, and so forth that keeps building truly accessible Web sites a real challenge.
It also got me to thinking that all the books and work I did on XHTML went exactly nowhere. There never really was that much interest in learning the new syntax and approach from the ground up: those who weren't using tools to generate markup anyway (more on that in a second) simply learned the syntax for XHTML 1.0 and switched over, without missing much of a beat. Though it took a while (2-3 years in some cases), for the major tools to catch up, nearly all of them from DreamWeaver and HomeSite, to Moveable Type, HTML-Kit, and hundreds of others now emit XHTML 1.0 (and in some cases, even XHTML 1.1) routinely and cleanly.
So what's the problem? For one thing, nobody really cares. Sites that re-use or repurpose content now routinely start in XML and view XHTML as just one of a possible set of output transforms their content can occupy. Sites that build Web pages or sites per se, mostly do so with tools that emit markup (and in some cases, even validate it) without too much muss or fuss. The only time that anybody really notices that XHTML has value is when they have to take it from that format and turn it into something else: then, XML's regular and well-formed syntax makes it a snap to do the presto!-chango! thing without a loss of muss or fuss.
Maybe it's better that way. But for those of us who still try to teach—or at least explain—the basic syntax and semantics of simple Web markup, XHTML remains preferable to HTML any day. Though I'd still like to figure out a way to avoid worrying about browser specifics without necessarily opting for simple structures and CSS based rendering, just to avoid complexity rather than tame it.
Ed Tittel is a writer, trainer, and consultant based in Austin, TX, who writes and teaches on XML and related vocabularies and applications. E-mail Ed at etittel@lanw.com.
