Mark caught me serving broken XHTML. I wish my browser had done me that favor.
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
In a comment on my Postel’s Law post, Mark Pilgrim quite correctly chastises me for serving broken content. This, he goes on to point out in a second comment, makes me a bozo and an incompetent fool, at least by Tim Bray’s metric.
What happened was this: even though each essay is carefully checked for well-formedness and even validity, that checking doesn’t resolve the server-side includes. One of those includes I create by hand. Last time I edited it, I carelessly wrote it in HTML instead of XHTML and got an empty tag wrong. (Another include had some bogus namespace declarations in it, but that’s not a well-formedness problem.)
Now, Mark was able to read the essay despite my error because his browser ignored the error. Mark calls this lucky. I dunno. I think there are two ways of looking at it:
Browser good. The browser is applying heuristics to recover from XML well-formedness errors, thus allowing users to read the content. Reading the content is what’s important and the browser successfully renders it.
Browser bad. The browser is applying heuristics to recover from XML well-formedness errors, thus masking problems that only a bozo or an incompetent fool would be unable or unwilling to fix. This sets the expectation that applications should recover from XML well-formedness errors. That would be wrong, not least of all because it introduces the possibility of much subtler and more serious problems later on, as one application’s set of heuristics differ from another’s.
I infer that Mark subscribes the former view. I subscribe to the latter. And I’m quite willing to play by the rules. The fact that browsers render broken content is a bug. Had they rejected the content as they should, it’s unlikely that my carelessness would ever have been seen by the public. At the very least, that would have saved me some embarrassment.