Why XHTML was doomed from the beginning

March 21, 2011

Yesterday I said that XHTML was an obviously flawed standard right from the start. I should actually clarify that, and then explain it. First, XHTML is probably not flawed from a strictly technical perspective (I don't have the expertise to be sure). Instead, it has always been flawed on the larger, social level of how nominal standards turn into real standards that people actually use.

(Ie, XHTML doesn't solve the real problem.)

The short version is that XHTML was doomed from the start because it ignored the reality of how actual people create actual web pages on the Internet. We can see this because of three mistakes it made: XHTML requires draconian error handling (in a decision inherited from XML), but you have to serve XHTML with a specific MIME type in order to trigger this (cf), and XHTML is renderable as HTML (and it looks basically right). The first decision is the fatal blow; the other two just add a lot of salt to the self-inflicted wound.

The core issue is that actual people create web pages not by reading standards but instead by a process that most closely resembles folklore. They vaguely know how things are supposed to work, they may peek with web searches or with 'view source', and they pretty much stop when the result renders the way they want or expect. People who even know what a validator is are a very small portion of the web authoring world, and always have been.

Draconian error handling is always going to be a massive failure in this environment, because people following this approach will always make lots of 'errors'. This leads to a terrible authoring experience where the typical person spends much of their time trying to get their browser to stop showing them a big yellow 'invalid XML' box, instead of doing interesting things like improving their content or how things look. People aren't exactly enthused about jumping through hoops to appease the computer instead of doing productive things.

(The other two decisions add salt because they cause lots of people to create invalid XHTML when they think they are actually authoring valid XHTML. This is an even worse failure mode than before in the long term.)

Any format with draconian error handling pretty much can't be written by hand, since people make mistakes; it has to be written by program, and ideally only a few programs that are carefully developed. Web page authoring has never worked this way, so XHTML's insistence on draconian error handling required a fantasy world where web authors would drastically change how they created web pages when they moved from HTML to XHTML.

(This omits all of the other pragmatic problems with draconian error handling, like programs with bugs.)


Written on 21 March 2011.
« The devil's advocate argument against paying attention to web standards
Some notes on doing things with Django model formsets »

These are my WanderingThoughts
(About the blog)

Full index of entries
Recent comments

This is part of CSpace, and is written by ChrisSiebenmann.
Twitter: @thatcks

* * *

Categories: links, linux, programming, python, snark, solaris, spam, sysadmin, tech, unix, web

This is a DWiki.
GettingAround
(Help)

Search:

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Mar 21 00:36:02 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.