> These are the same people who created XHTML, an ivory tower idea nobody was waiting for
I never understood what people had against XHTML. The more common theme seems to be "XML... eww" and nothing else. Can anybody help me understand?
I never understood what people had against XHTML. The more common theme seems to be "XML... eww" and nothing else. Can anybody help me understand?
For a reaction from a browser developer, see https://dbaron.org/log/20090707-ex-html
But getting everyone else to start over as well was always going to be an uphill struggle even if it was truly the best thing ever.
Yes, it was a requirement that XHTML 2.0 documents be served as application/xhtml+xml (which IE didn't support at the time), but that was really a non-issue (with so much renamed and moved around v. HTML 4.01 and its XML reformulations (XHTML 1.0, XHTML 1.1) because there was no graceful fallback story.
The bigger problem was that it required content to be served as application/xhtml+xml, and gave the same element and attribute names, in the same namespace, different semantics to what XHTML 1.0/XHTML5 gave them, with different implementation requirements (and it being impossible to satisfy both).
AFAIK this essentially got resolved by XHTML 2.0 being abandoned (in 2009, years after HTML 5 had moved to being jointly developed with the W3C).
In these days of Typescript, where web devs seem to like having stricter rules, it could play better. But that ship has already sailed.
Or you import a small Javascript library from 1999 that generates its own innerHTML for a few elements, but does it with HTML. Oops.
Or you built a new CMS with shiny XHTML markup, but before you had the CMS your org just hand-wrote pages which you now need to parse and import into the CMS.
These were all very real considerations in the 2002-2004 period; I've dealt with all of them. Backwards compatibility is often the most important feature you can offer, because it directly affects the value the end user gets out of the product. Sites that were concerned with "doing it right" in that time period largely failed, while sites that "did it fast" in a hacky, XSS-prone way are now worth hundreds of billions of dollars.
There was also similar exposure from the data side; as the amount of data you handled increased, the odds that some data would tickle some code path that you didn't even know could blow up went up. You write your news front page in XHTML, and everything seems fine for six months, until someone finally includes an ampersand in their headline, and your entire front page crashes for two hours (not in any way monitoring will pick up, either, so you're getting customer reports), and it takes you hours to discover that someone was passing through the headline (and just the headline!) unencoded.
The problem isn't XHTML's rigidity per se; personally I'm inclined more in that direction myself. The problem is when you have a ton of sloppy systems working together (MySQL, old HTML generation code, plugins from third parties your don't control, open source written by people whose belief in their understanding of HTML exceeds their actual understanding, decade-old internal databases with poor validations and unknown provenance, and so on and so on indefinitely), and then trying to suddenly, at the last minute, couple that big sloppy pile of technology to a strict technology at the last second. That sudden mismatch there at the end was a huge problem.
One of the reasons I tend to prefer being as strict as possible is that in general, starting with existing strict-tech and adding sloppy-tech to it is no big deal; the sloppy tech doesn't complain that it only gets a subset of possible data it will accept. And if you need to couple to strict-tech, you still can. But if you start with a sloppy-tech system and for some reason need to couple it to a strict-tech system... prepare for some long nights and blown deadlines. So, professionally, the correct default is to choose strict-tech whenever possible. But XHTML forced that at almost the worst possible place.
In most cases, if your code has some syntax error, the author of the code sees the syntax error; in the web case, if your code has some syntax error, the user sees the syntax error. That's the dramatic difference.
The other reality is unlike program code, there's vastly more often user content intermixed in (X)HTML and it's rare for people to implement sanitisation correctly (do you handle U+0000? U+FFFF? U+1FFFF? most people outputting XHTML historically haven't, even if they get the security critical stuff (like "<") right).
Good writers of markup will always check with those before they ship it. In the case of user supplied markup, that's still an issue today with HTML.
The reality ten years ago, when a number of prominent XML advocates were using XHTML (and actually using it as such, serving it as such), almost all of their sites had user input means where the input was sanitized well enough for HTML to be secure (and not have any markup injection), but not for XML well-formedness (they got all the markup injection risks in XML, but not all the other WF requirements). If the very people who claim XML is easy can't get it right, can everyone else?
I, too, served my web pages as "real" xhtml 10 years ago and loved it :)
Hence the “ivory tower” comment upthread.
The browser is a communication channel between a publisher and a reader. They may want different things...
But the "semantic, well-formed, machine-readable web" idea is, in theory, a demand that the channel imposes on both parties. It's not something the publisher wants. It's not something the reader wants. Nobody cares what the channel wants; demanding extra information that isn't relevant to what any party to an actual transaction is trying to accomplish is always going to be doomed.
Readers care about positional information at a fairly minor level. Publishers care about it a lot. And hey, positional information has robust, if annoying, implementations.
We did get a handful of different names for a div though, so that's nice, maybe.
> The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML.
Basically, XML's purpose was to make parsing rules for web documents generic and DTD-less, in particular to support new vocabularies (eg. SVG and MathML) in addition to HTML/XHTML. The XML namespace spec back then was another pillar for advancing that goal.
HTML5 then simply imported SVG and MathML into HTML as external vocabulary, without a need for namespaces or other modularization meta-technique.
That XML has failed on the web (and was succesful only in enterprise and publishing) shouldn't make fans of structured documents on the web bitter, though: SGML is exactly as capable as XML to describe the syntax of markup documents (with tag inference, a feature recently being discussed for re-inclusion into XML under the term invisible markup), and even can parse markdown and other Wiki syntaxes, can do HTML-aware, injection-free macro expansion, and a whole lot of other things waiting to be discovered by XML fans.
XHTML continued the spirit of HTML 4 strict, getting rid of presentational elements and replacing them with 'sematic' ones. Eventually, you were also supposed to combine it with RDF to embed machine-readable metadata into your documents (cf https://www.w3.org/2003/03/rdf-in-xml.html and https://en.wikipedia.org/wiki/XHTML%2BRDFa ).
But it undoubtedly makes development harder. Web Developer 101: Section 1: This 20 page list of categories and their strict formal definitions.