Sellings strings on the street corner and the War On XML

After encountering an XHTML parsing error on a web shop, Anne van Kesteren rails against draconian error handling:

It was not fixed within sight of the error as you would expect. I guess it did not get unnoticed that all those people who love draconian error handling and the “strictness” of XHTML claim that the beauty is that sites get fixed fast. You are all wrong. The real world does not play ball. The error is still there and will only be fixed once the owner of the shop notices the error (he uses Internet Explorer, so never) and contacts the incompetent fool who stopped me from buying games to fix the damn error. He might as well sue him for hurting his business.

If there’s any proof that even draconian handling does not get sites fixed fast here, I can’t see it. What I see is a real-world demonstration of the very reason that delivering XHTML as text/html is considered harmful: the people who can fix the site get tagsoup, whereas those who visit get draconian handling. That’s an incredibly stupid move, by any standard.

But it proves nothing about what would have happened, had the shop owner been served XHTML as application/xhtml+xml. (Not possible because he uses Internet Explorer, you say? Oh, but you can certainly use XSLT to transform the page to HTML on the server when delivering to IE. There you go, a real XML parser. There are more ways, too; use your imagination.)

I am puzzled that Anne would put up such a flimsy argument. I know he knows better than me why serving XHTML as text/html is bad.

Certainly, the shop owner should sue the fool who is hurting his business. Running a site that serves (purported) XHTML on a backend that isn’t XML from top to bottom is gross negligence. But serving (actual) XHTML in itself? No, that does not hurt business.

Don’t glue strings together and sell them as XHTML, kids. That will rightly get you sued.

Update: Dominic Mitchell says I missed the real point:

When you’re working with some server-side framework, variables are almost invariably output as-is. […] The default should be to escape everything that’s output, unless the programmer asks otherwise.

Actually, that’s exactly what I mean when I say “you shouldn’t glue strings together.”

That’s exactly why I plan to port Kid to Perl. (And yes, it would qualify as a bad mix of code and template, but that’s an argument for another article, one I have been working on for a while.)