> XML it makes sense, since it's a data format, not a
> document format. XHTML is not a data format, it's
> displayed to the user. Which is bad.
All documents are data. All document formats are data formats.Most formats use strict error handling; SGML's lenient handling is actually very rare. If you removed random sections from a Word document, or a PDF, or en eBook, that document would then be un-renderable. I have never heard it claimed that .pdf is unsuitable for display to users because it is not resistant to arbitrary corruption, and it's silly to make this claim for HTML/XHTML. 20 years ago, HTML was written by hand, in plain text editors. There was absolutely no validation performed between the author's keyboard and the user's web browser. This model is no longer practical for modern web sites, but some developers have refused to alter their behavior. XHTML requires authors to perform a minimum of validation before sending markup to the browser. The holdouts are used to just writing up a website and clicking "save", so they complain bitterly. But anybody who uses a template engine will not care, because they are used to the idea that what they write is not identical to what the browser receives. To these developers, supporting XHTML is a simple matter of changing a setting in their template library. |
The DOM is simply a way of representing HTML for scripting access and whatnot.
Second, it is not to be resistant to corruption, it's to be resistant to human error. Also, many formats ARE resistant to that, thanks to various error correction algorithms.
Have you ever heard the story behind kernel panics? Errors should not be shown to end users when they are recoverable. Errors happen every second, if we let them all out, computers would be unusable.
Thirdly, that "XHTML is easy" assumes that everybody has embraced HAML or Jade or other sugary templates. I personally find they all suck horribly, so I use Handlebars (a Mustache variant) and write the HTML myself.