JSON errors are worked around by developers, we don't display an error and kill everything if it doesn't format right, plus it's a lot simpler.<p>XHTML/XML errors are displayed to the user, and the idea of "being strict" is fine for development, bad for release.<p>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.<p>Lastly, WTF ABC? Really, guys, serving XHTML based on UA? What the hell went through your heads that made that seem like a good idea?
If I'm reading that page correctly, then abc.com is using User-Agent instead of Accept to determine whether the client supports XHTML. This seems like a really bad idea; what happens if (for example) someone uses user-agent spoofing to get desktop sites, and ABC serves up a mimetype that it can't handle?<p>Additionally, I'm baffled as to how any reputable site can actually serve invalid XHTML. The template engine should have logic similar to "if the client accepts XHTML, send XHTML, otherwise send HTML". To exhibit the behavior seen in this post, ABC's site must instead do something like "send the client HTML. if its user agent matches <regex>, claim you sent XHTML".<p>Somewhere in the bowels of ABC's IT department, there's a very confused intern with a copy of Web Programming for Dummies.
Why is anyone still using XHTML? I thought HTML5 had mercifully obsoleted that.<p>I for a long time bought into XHTML, just to find out that XHTML documents render <i>slower</i> than plain ol' HTML ones, and pretty much nobody was able to produce proper XHTML anyway.