Yes, it seems reasonable, and the analogy with programming languages seems to make sense. But there's a big difference. With programming languages, you write a program, and when it's correct, you check it in and it's immutable until you check in a new version. Web pages are composited on-the-fly by programs that combine static files, database content, content from third parties, etc. The only way you guarantee a valid output document is if your compositor is bug free and defensively validates any third-party content you might be pulling in. Any bug in the compositor and your website is totally unavailable for users that hit the bug.
Thanks for the link. I can certainly see how making the transition now is pretty much untenable, but I'm not 100% sold that it wouldn't be a good idea if everyone had adopted the policy from the start. I can certainly see how it would still be important for browsers to have a mode where they do their best to render the page, but it's less clear that it should be the default. Even if it was the default, then I would expect variations in different browsers ability to recover from errors would lead developers to being much more careful about allowing errors to creep in.
What makes that story (in my link) so compelling to me is that it happened to people who were XHTML advocates. They were the people arguing that browsers should be strict. They were the people writing blogging software The Way It Should Be Done, to ensure maximum XHTML compliance. It was a blog entry that was specifically arguing for strict parsing that it became invalid XHTML due to a bug.
If true believers can make this kind of mistake, how often will it happen to people who are just trying to get work done? People will have bugs in their code sometimes, but what should the failure mode be?
Yes, but if browsers were strict by default (or at least by default in dev mode), the bug in his compositing software likely would have been found and fixed much earlier, and it wouldn't have persisted into production.
So again, I understand that it's nearly impossible to make the transition now, but that doesn't mean it wouldn't be preferable. And there's no reason the transition couldn't still be made, but much more slowly, and perhaps without ever making the big browsers reject by default.
I don't know if there are other disadvantages to XHTML, but if the strictness issue is the only one, then it seems like there would still be value in slowly transitioning over.
This is a great illustration of the concept: https://web.archive.org/web/20060613193727/http://diveintoma...