XHTML Considered Harmful

On Sat, 23 Jun 2001, Ian Hickson wrote:

> What's wrong with XHTML sent as text/xml?

XHTML is by far the silliest puff of hothouse XMLing-for-its-own-sake
to have wafted out of the W3C.  It is bad engineering from beginning
to end, and as such, constitutes a prime example of how text/xml - as
the means to deliver XML applications - could become an unworkable
mess through dogmatic advocacy of *bad* designs.

We can understand RFC 1866 as the closure of an historical process,
and file it away as a "noble experiment".  The successor specs, in
persisting with the myth of "Conforming SGML Application", were only
means to stave off the (imagined, if not feared) embarassment of
having actually to concede irrelevance.  The trouble all along has
been that SGML is a formalism geared towards design[1].  Using it to
pick up the dirty laundry trailed by beer-and-pizza programmer jocks
has entailed a steadily growing list of "application conventions",
half-hearted deprecations, and copious prose which perforce is all the
more sumptuous whenever the point has been not to try hard to say
something but to try hard to evade something.  The result: a rambling
catalog of circumstantial specifics and ponderous bombast, with the
overall coherence and elegance of a bag of potatoes.

Retrofitting SGML onto a mass of lumps was bad enough, having another
go with XML is worse, pathetic if it weren't grotesque.  In a parody
of ontogeny recapitulating phylogeny, the fact of XML being a limited
profile of SGML is reflected in the morphological simplifications of
the XHTML spec.  Evasions couched in apologetic "shoulds" have become
absurdities couched in "musts"[2].  Highminded circumlocutions have
become explicit guidelines for "compatibility".

If anything, the compatibility guidelines are a demonstration of the
intellectual bankruptcy of the entire exercise.  Where the entire
point of a "compatibility" rubric is to suggest that XHTML *is*
deliverable as text/html, it is less than edifying to learn that the
compatibility in practice involves a reality that the W3C has spent
years denying, because it takes *ignorance* of SGML for all this
XML-ized stuff to "work" in "HTML user agents".  Inter alia, the
hapless innocent who doesn't read between the lines is left to find
out the hard way that validation of XHTML and of HTML4 documents are
distinct and incompatible considerations.  That's the fate of the few
who commit to taking W3C specs *seriously* - double the work for no
gain in benefits.  

The practical consequence, of course, is that people will gravitate to
what works for them.  Haranguing them with XHTML hype will only serve
to evoke in them the desire to have what is already working continue
to work ("Show me!").  Market Pressure - ignore it if you like, it
won't go away - will be for text/html instances to be acceptable as
text/xml.  Not as geeks immersed in W3C theology understand text/html
and text/xml, but as non-geek users of "popular implementations" will
understand them.

Not only is XHTML a hostage to fortune, its frankensteinian presence
also serves to inhibit alternatives.  XML was - and perhaps still is -
an opportunity for small rationalized modules as the results of a
*design* effort.  The point would be not to serve the same old stuff
in a new way, but to have *new* stuff that people could choose to take
up because they *lose* nothing.

So, what's wrong with XHTML sent as text/html?

One word: compatibility.  It says all the wrong things, and prevents
all the right things.


[1]
  http://listserv.heanet.ie/cgi-bin/wa?A2=ind9508&L=html-wg&P=R14154
[2]
  http://lists.w3.org/Archives/Public/www-html/2000Jan/0255.html
  http://lists.w3.org/Archives/Public/www-html/2000Jan/0246.html 


Arjun

Received on Sunday, 24 June 2001 22:19:38 UTC