Lately I have been trying to pin down exactly why I feel a little uneasy about XHTML and I am beginning to think the reason has more to do with its’ perceived purpose rather than a deep criticism of the language itself. XHTML has always felt like a puppy, blind in one eye, trying to run uphill with uneven appendages. It’s awkward, it’s clumsy, and even though it will get to where it needs to be, the trip is hardly ever graceful.
Most modern websites roughly follow this process:
- The user requests a resource.
- The server determines the most recent version of the data.
- The server wraps the data in XHTML so the data can be understood by the web browser.
- The web browser applies CSS so the data can be understood by the user.
The logical assumption is that XHTML very closely resembles the data but we all know that assumption is wrong. We know this because whenever we want a machine-to-machine interaction via a web service we swiftly exclude human observation and make heavy usage of XML formats intended only for machines to see such as RSS. In fact, RSS makes a powerful example of this because it has become so widespread and popular that modern web browsers have started to apply their own presentation to RSS documents so that the user is offered something more meaningful for them.
The reality of all this strikes me as completely backwords and not at all what I envision as being the “semantic web”. We began with a web where machines had great difficulty extracting anything meaningful to them and we’re now heading towards a web where machines get meaning from documents that a user would never be able to extract meaning from. The ideal reality would be a marriage of the two where the user and the machine are both able to extract something meaningful from the same document. I believe this is what I and many other web developers have tried to make XHTML do, and certainly it is not pointless to make meaningful markup, but to pretend that XHTML is all that useful to machines is naive at best.
I don’t think having portions of the web unreadable for humans is necessarily wrong or bad, there needs to be a place for API’s and the like, but I do feel like this says something about making XHTML documents with an attitude that it will be read by something other than a search engine.
The conclusion I am coming to now is that XHTML should be strictly considered presentational glue and never attempt to communicate anything meaningful through it. Instead use other XML standards and be adventurous enough to develop your own meaningful XML formats to replace segments of XHTML. XML, XSLT, and CSS has been supported by all modern browsers for some time now but only a small percentage of web developers make use of anything other than XHTML.
Why have I not seen more XML formats for menus? I’m not even concerned with standards at this point. I’m more interested in just seeing some experimentation. Instead the standard seems to be something in the form of a cleverly named “div” or “ul” instead of a carefully crafted “sitemap“.
I definitely plan on identifying more areas where I can inject more meaningful XML. Assuming I don’t run into any CSS-related problems with IE, I would like to experiment with replacing the “table” element in some circumstances and using CSS to display the data to the web browser as table rows and cells. Hope this at least stirred some thought and encourages some experimentation.




2 Responses to “XHTML is not really about the data”
November 25th, 2006 at 8:29 am
Andreas Says:
lol
Accualy I do not think as you in that thing
Nice site by the way.
/Andreas @ www.Andreasdesign.se
December 5th, 2006 at 1:57 am
John Says:
very interesting ideas. i’m surprised no one else has commented this yet. as you so desired, it stirred thought in me. keep the ideas coming-