The Web's Future: XHTML 2.0
Lee writes "Over the years, HTML has only become bigger, never smaller, because new versions had to maintain backward compatibility. That's about to change. On 5 August 2002, the first working draft of XHTML 2.0 was released and the big news is that backward compatibility has been dropped; the language can finally move on. So, what do you as a developer get in return? How about robust forms and events, a better way to look at frames and even hierarchical menus that don't require massive amounts of JavaScript. This article takes a sneak peek at what's new in XHTML 2.0 and how you might one day put it to use."
I'm all for the advancement of standards and the cleanup of bad practices sanctioned by older HTML, but we all know this changes nothing in our immediate future. Most normal (non-Slashdot-reading) users aren't going to download and install the browser of the week, and most web authors aren't going to go back and rework all their web content for new standards.
Browser behaviour is (or should be) determined by the !DOCTYPE element in an HTML document. What they mean is that if a page has an XHTML/2.0 doctype, it will not support all the cruft that was left in XHTML/1.0 and 1.1 (left in for the purposes of backward compatibility).
If a page doctype claims the page is HTML/4.0 or HTML/3.2, then none of these new rules should apply.
Liberty in your lifetime
Style sheets mean less code, not more. An XHTML/CSS page is cleaner and simpler than older pages - less spacing tricks (non-breaking spaces, invisible images, convoluted tables), more consistant code, less repeated tags.
As a programmer myself, I don't see why you are more confortable with micromanaging <font> tags rather than defining the page properties once in one central place. Hell, if you want, you can just use embedded style rules and put style="font-family: Verdana" right in the tag you would have wrapped in a <font></font> tag.
As horrible as it sounds, XHTML2 and a very basic XSL could make this nightmare of yours an extremely simple and automated proccess.
Luckily, server-side scripting and web servers have advanced since iplanet. Two lines of PHP could sniff the client's browser and then fill xhtml2 or fail-safe to xhtml1.1, without the user ever knowing.
The point, however, is that it is almost no trouble to do an XSL translation from XHTML2 to XHTML1 or even HTML4. The reverse is not true. Website back-ends can be updated to take advantage of XHTML2's more concise and descriptive format, while XSL produces an antique but perfectly valid HTML4.01 public face. The results are easier maintenance, modulized structure, and enough context to generate valid markup for any earlier version of HTML.
Backwards compatibility? XSL with XHTML2 gives you the ultimate in backwards compatibility! It can give you valid markup for EVERY version of HTML, as appropriate for your public site's demographic.
I'm as mimsy as the next borogove but your mome raths are completely outgrabe.