Have you ever seen an error message like this one? XML parsers are designed to call it quits as soon as they encounter an error. XML grammar is strict, so the parsers need to be strict too. This particular error is from an
& in a URL.
&s in URLs are super common occurrence, but if you throw one into a plain XML document, without inserting it as a character entity (
&) or numerical character reference (
&) you get an error.
To be honest, I’m not a huge XML hater. I’m a technical guy so ensuring that some of the documents I create adhere to a technical standard doesn’t kill me.
I mean, Ant.
That said, I don’t like the way XML’s strict error handling inserted itself into the web with xHTML. A good part of the reason the web blossomed the way it did was because the language underpinning it, HTML, it was so forgiving people could get by without knowing what they were doing. My initial HTML was so bad, I’m surprised I ever did anything.
But yet, I did.
And I’ve been building sites since. 17 years and counting! All because I could create a tag-soup mess that, kinda/sorta did what I wanted it to do and the browsers at the time did their best to try to make sense of it. That was great.
XML/xHTML took that possibility away. Which is why, while many people (including myself) wrote xHTML documents, we didn’t actually serve them as XML. The danger of having a catastrophic error was too great, so all but the hardiest developers basically treated xHTML like HTML 4.0, just with XML style syntax.
Which is kinda’ goofy.
Remember when they said “Users should not be exposed to authoring errors?”
The group that went on to found the WHATWG (the group responsible for the current HTML specification) recognized that this was a serious flaw and put a specific reference to this issue with xHTML in their proposal for the future of web application development. It was one of their seven guiding design principles. In case you’re unaware of the history, that paper is the foundation of the modern HTML specification. One piece of that foundation is as follows:
Users should not be exposed to authoring errors
Specifications must specify exact error recovery behaviour for each possible error scenario. Error handling should for the most part be defined in terms of graceful error recovery (as in CSS), rather than obvious and catastrophic failure (as in XML).
These are concepts embedded in the very heart of modern web development.
- Avoid catastrophic errors.
- Allow for graceful error recovery.
I understand that creating a completely static version of your site or application is impractical. Granted. Still, showing nothing if there’s a problem is just terrible. But yet, people are happy to do it.
What’s wrong with progressive enhancement?
Your users don’t care how fancy your stack is. They care that they’re getting their content, that they’re getting it as fast as possible and it appears consistently from visit to visit. If your stack is getting in the way of any of those goals then you need to revisit the way you’ve designed your web solutions.