22 September 2000 - Easily Manipulated Content
A lot of Web developers take a glance at XHTML 1.0 and see a lot more work, new rules to adhere to, and new compatibility problems to deal with. It's true that XHTML is more work in the short term, but beyond that initial work lies promise that goes well beyond the limited vision of 'Dynamic HTML' that currently defines the outer limits of HTML user interface design.
While XHTML may seem like a recipe created by neat freaks, its insistence on orderly and predictable structures has enormous benefits. As Dynamic HTML developers have learned over the years, it's much easier (and far more predictable) to manipulate document structures when the boundaries of those structures are clear.
A lot of Web developers don't want to manipulate their documents. They see their HTML documents as carefully crafted and set in stone, with no need for scripting or other supplemental poking. After all the work that goes into layout, further manipulation seems like the last thing anyone would want. It adds to the maintenance cost of a site, it requires different groups of developers to coordinate their efforts, and it often produces results that satisfy none of the participants.
Web development isn't just about producing documents, though. Web sites send information to customers, some of whom keep track of that information or process it further. Search engines are an obvious example of this processing, but tools that can take HTML and format it for print or agents that seek out information automatically are just a few of the additional possibilities that become easier to implement when document structures are coherent and clear.
XHTML also opens new vistas in document storage, management, and reuse. The clean structures make it easy to reference content by its location in a document, simplifying cross-references. Sophisticated document storage systems can give different pieces of XHTML documents to different editors for simultaneous (but non-conflicting) editing. Sites that need to present their information in other formats, like Wireless Markup Language (WML) can define transformations of XHTML documents without having to run everything through a database.
Maybe 'no pain, no gain' is a difficult things to sell to Web developers who won't see much benefit from XHTML today, but the possibilities XHTML opens are real. XML developers are already taking advantage of many of these techniques, paving the way with tools and experience the Web development community can use.
20 October 2000 - What to convert to XHTML first
While developers are starting to poke at XHTML, most existing Web sites already have enormous quantities of information stored in HTML which may or may not be XHTML-friendly. Worse, pages generated by CGI, ASP, or other scripting technologies may not be easy to change. Where should developers start?
In general, there are two rules that can provide some guidance. Content that may need to be delivered in multiple formats can take enough advantage of XHTML to justify the cost. Some content is simply easy to convert to XHTML simple documents where Tidy can do all of the work, or new documents where using XHTML from the start inflicts less cost than conversions from older HTML.
The biggest advantage XHTML 1.0 gives developers is the ability to repurpose content using XML tools - you can, for instance, create transformations from XHTML to Wireless Markup Language (WML) using XSLT stylesheets or DOM scripts. If you have documents for which delivery in multiple formats is critical, you may want to consider storing them in XHTML, or even generating XHTML from custom XML vocabularies.
Converting documents because they're 'easy' is pretty subjective, since everyone seems to have a different definition of 'easy.' Simple HTML, where layout is mostly headlines and paragraphs, can generally be converted with very few blips. Complex layouts using tables, gifs, and the occasional creative whitespace hack can be much more difficult, especially if you feel constrained to preserve the exact look of the original document in every browser environment it served. (Recent browsers make XHTML work much easier.)
New projects can benefit immediately from XHTML's cleaner structures. The discipline of cleanly nested structures will have an effect on the level of discipline in code used to generate documents, and may help Web developers build more maintainable projects. (Yes, I know that's likely a dream.) Developers using client-side scripting to build dynamic HTML sites will also find XHTML easy to work with. Many of these developers have already adopted some of XHTML's strictures to mark structures more precisely.
Even projects which won't benefit immediately may want to transition to XHTML for new work - if nothing else, it means that future transitions should be much simpler.
For more information about this list, visit the main page.
Copyright 2000 by Simon St.Laurent