Manage Learn to apply best practices and optimize your operations.

The benefits of "back-revs"

Don't be on the cutting edge with XML development, unless you want to do a lot more work.

The benefits of "back-revs"
Ed Tittel

Were I to sum this tip up in a single sentence, it might read: "It's better to stay one revision back from leading edge markup-language specifications, particularly when browser vendors haven't yet implemented the functionality required to understand or render recent changes, enhancements, or additions." To be more specific, I've been working on a trio of XHTML books wherein we've tried not just to explain, but also to explore and display some of the cool new capabilities that XHTML 1.1, in all its modularized glory, can display.

There's just one small problem that's been driving me bonkers--namely, none of the browsers that I know about can digest and display some of the newest markup properly.

Of course, I could take an XML capable browser (say, for instance, IE 5.5 with MSXML 4.0 installed), write the style sheets necessary to make this new markup look like something, and kludge something together, but I've barely got enough time to figure out how to make the core functionality work, let alone to create a supporting display infrastructure for that new markup.

In desperation, I turned to some friends at the W3C who worked on one particular module--namely ruby annotation (ruby is the size of the small print typeface routinely used in the Far East to annotate ideograms from one language like Mandarin or Hangul with ideograms from another language such as hiragana or Thai)--to see how they solved the problem of showing examples for markup that no browser yet supports. I learned that they, too, had to resort to trickery to create displays that would otherwise be impossible to use as illustrations. They turned to complex HTML tables with extensive layout controls to create the appearance of what ruby annotation will no doubt do automatically once the browser vendors get around to supporting it.

Along the way, I learned a lot about some new markup capabilities and made some new professional friendships. But I also spent far more time--3.5 days of work on a chapter that was supposed to take me half a day to write--than I had intended to. This latter circumstance led me directly to the realization that appears in this tip's title. That is, if you are building a production Web site, it's best to limit yourself to markup that ordinary run-of-the-mill browsers can display.

Of course, the beauty of XML (and by extension, XHTML) is such that you could use the unsupported markup anyway. You'd just have to take the time to write an XSLT transform that would parse the unsupported markup, turn it into a form that current browsers can indeed handle, and ship it on to end-users without them having to know about the cartwheels you're turning in the background. A corollary to this tip could therefore read: "If you must use unsupported markup, turn it into something supported before it ever hits the browser." As soon as I get some time, I'll do that very thin.

Have questions, comments, or feedback about this or other XML-related topics? Please e-mail me at; I'm always glad to hear from readers.

Ed Tittel is a principal at LANWrights, Inc., a wholly owned subsidiary of LANWrights offers training, writing, and consulting services on Internet, networking, and Web topics (including XML and XHTML), plus various IT certifications (Microsoft, Sun/Java, and Prosoft/CIW).

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.