5 ms·

> 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 the

by klez 7y ago

> 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?

ChrisSD 7y ago
IIRC, the main objection was that error handling was an all or nothing affair. Whereas most HTML on the web is (or was) broken to a greater or lesser degree. There was also the objection that stricter parsing made it harder for hobbyists. In these days of Typescript, where web devs seem to like having stricter rules, it could play better. But that ship has already sailed.
- sureaboutthis 7y ago
  I never understood that either except, as you said, for the hobbyist's sake. A lot of XHTML was generated from XML and, if one is using XML, chances are programming is involved in the transformation to XHTML. But programming has strict rules itself and will also fail if not adhered to so I never understood the complaint of "draconian" error checking in XML/XHTML.
  - gsnedders 7y ago
    > But programming has strict rules itself and will also fail if not adhered to so I never understood the complaint of "draconian" error checking in XML/XHTML. 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).
    - sureaboutthis 7y ago
      Not true. XHTML and HTML have validators to check your markup for proper syntax and usage. You know that. You made one of them! 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.
      - gsnedders 7y ago
        I've been involved with multiple HTML and XML parsers, but never validators. :) 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?
        sureaboutthis 7y ago
        Yes. It was your outliner I was thinking of, not a validator but weren't you involved with the original http://validator.w3.org/nu/ http://validator.w3.org/nu/ at least in part? I, too, served my web pages as "real" xhtml 10 years ago and loved it :)
        gsnedders 7y ago
        Promise I've never worked on a validator!
        sureaboutthis 7y ago
        Well, now I have to rewrite my book :)
  - jerf 7y ago
    As the scale of a program increases, the probability that someone will do something wrong increases polynomially. Consequently, as web sites got larger and larger, the probability that some component would break the XML goes up quickly. This is a difficult pattern to deal with, pushing up the skill floor required, and as HTML5 shows, it isn't even all that necessary. 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.
  - nostrademons 7y ago
    People underestimated the extent to which markup may be mixed in from sources you didn't control, and the power that this ability gives to your users. Say you built a shiny new forum engine with from-scratch XHTML markup. You try to sell it. Most of your customers say that they've already been running forum software since 1995 but the existing posts allow inline HTML (which was less unsafe in 1995, because no Javascript), which is all badly misnested. As soon as they dump the previous data, their site stops working. 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.
pbhjpbhj 7y ago
Agreed, I was all-in on XHTML, I'm still smarting that HTML5 won with the seeming death of the semantic web. We did get a handful of different names for a div though, so that's nice, maybe.
- tannhaeuser 7y ago
  I don't see this connection of XHTML and semweb. The preamble to the original XML spec reads as follows: > 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.
  - cygx 7y ago
    I don't see this connection of XHTML and semweb 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 https://www.w3.org/2003/03/rdf-in-xml.html and https://en.wikipedia.org/wiki/XHTML%2BRDFa https://en.wikipedia.org/wiki/XHTML%2BRDFa ).
    - WorldMaker 7y ago
cygx 7y ago
The error handling has already been mentioned. There also was that issue of what mime-type to send in your HTTP headers to get the page displayed correctly in various clients. While you could develop in XHTML, you needed to serve it as technically broken HTML to be compatible with older browsers that still had a significant market share.
- geezerjay 7y ago
  Sounds like the complains are targetted at faulty implementations, not the document standard.
  - dragonwriter 7y ago
    Yes, that the standard wasn't designed with the people actually implementing browsers and as a result was unusable for content in the real world whatever advantages it had in the theoretical world where it was widely and correctly implemented was a major problem. Hence the “ivory tower” comment upthread.
    - geezerjay 7y ago
      The expression "ivory tower" has an entirely different meaning. Just because the couple of dominant players chose to ignore a standard, particularly in a time and age where they were outright hostile to interoperability initiatives, it doesn't mean the standard was not reasonable.
  - cygx 7y ago
    What good is a standard you can't use in practice? There also were other issues: XHTML was chasing the dream of the semantic, well-formed, machine-readable web, but it didn't do enough to help with pragmatic problems web designers trying to deliver a product actually faced. As much as I like the idea myself from a theoretical perspective, the market had other priorities.
    - thaumasiotes 7y ago
jcranmer 7y ago
This isn't against XHTML 1.1, which was HTML 4.01 shoved into a container of "if it isn't valid XML, display an error page instead;" rather, a lot of the hate is against XHTML 2.0, which decided to rip out HTML features such as forms, frames, most of the old elements such as <b> or <i>, and generally screw compatibility completely. For a reaction from a browser developer, see https://dbaron.org/log/20090707-ex-html https://dbaron.org/log/20090707-ex-html
- ChrisSD 7y ago
  Ooph yes. I had forgotten how they were rewriting HTML essentially from scratch and this time basing it on XML. In fairness, it wasn't a completely dumb idea as HTML had picked up a lot of warts from its long history and anyway almost no browser implemented the HTML spec as written. The browser wars especially spread a lot of debris across implementations. The temptation to rip it up and start again is very strong with software engineers even in the best of circumstances (heck, just ask Google about this). 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.
- amyjess 7y ago
  XHTML 2.0 also did screwy stuff with MIME types I believe. It required specific MIME types that a lot of browsers at the time didn't support, and because of that most browsers would straight-up refuse to render XHTML 2.0.
  - gsnedders 7y ago
    That… wasn't even the screwy stuff. 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).

by klez 7y ago

ChrisSD 7y ago

IIRC, the main objection was that error handling was an all or nothing affair. Whereas most HTML on the web is (or was) broken to a greater or lesser degree. There was also the objection that stricter parsing made it harder for hobbyists. In these days of Typescript, where web devs seem to like having stricter rules, it could play better. But that ship has already sailed.

sureaboutthis 7y ago
I never understood that either except, as you said, for the hobbyist's sake. A lot of XHTML was generated from XML and, if one is using XML, chances are programming is involved in the transformation to XHTML. But programming has strict rules itself and will also fail if not adhered to so I never understood the complaint of "draconian" error checking in XML/XHTML.
- gsnedders 7y ago
  > But programming has strict rules itself and will also fail if not adhered to so I never understood the complaint of "draconian" error checking in XML/XHTML. 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).
  - sureaboutthis 7y ago
    Not true. XHTML and HTML have validators to check your markup for proper syntax and usage. You know that. You made one of them! 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.
    - gsnedders 7y ago
      I've been involved with multiple HTML and XML parsers, but never validators. :) 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?
      - sureaboutthis 7y ago
        Yes. It was your outliner I was thinking of, not a validator but weren't you involved with the original http://validator.w3.org/nu/ http://validator.w3.org/nu/ at least in part? I, too, served my web pages as "real" xhtml 10 years ago and loved it :)
        gsnedders 7y ago
        Promise I've never worked on a validator!
        sureaboutthis 7y ago
        Well, now I have to rewrite my book :)
- jerf 7y ago
  As the scale of a program increases, the probability that someone will do something wrong increases polynomially. Consequently, as web sites got larger and larger, the probability that some component would break the XML goes up quickly. This is a difficult pattern to deal with, pushing up the skill floor required, and as HTML5 shows, it isn't even all that necessary. 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.
- nostrademons 7y ago
  People underestimated the extent to which markup may be mixed in from sources you didn't control, and the power that this ability gives to your users. Say you built a shiny new forum engine with from-scratch XHTML markup. You try to sell it. Most of your customers say that they've already been running forum software since 1995 but the existing posts allow inline HTML (which was less unsafe in 1995, because no Javascript), which is all badly misnested. As soon as they dump the previous data, their site stops working. 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.

pbhjpbhj 7y ago

Agreed, I was all-in on XHTML, I'm still smarting that HTML5 won with the seeming death of the semantic web. We did get a handful of different names for a div though, so that's nice, maybe.

tannhaeuser 7y ago
I don't see this connection of XHTML and semweb. The preamble to the original XML spec reads as follows: > 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.
- cygx 7y ago
  I don't see this connection of XHTML and semweb 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 https://www.w3.org/2003/03/rdf-in-xml.html and https://en.wikipedia.org/wiki/XHTML%2BRDFa https://en.wikipedia.org/wiki/XHTML%2BRDFa ).
  - WorldMaker 7y ago

cygx 7y ago

The error handling has already been mentioned. There also was that issue of what mime-type to send in your HTTP headers to get the page displayed correctly in various clients. While you could develop in XHTML, you needed to serve it as technically broken HTML to be compatible with older browsers that still had a significant market share.

geezerjay 7y ago
Sounds like the complains are targetted at faulty implementations, not the document standard.
- dragonwriter 7y ago
  Yes, that the standard wasn't designed with the people actually implementing browsers and as a result was unusable for content in the real world whatever advantages it had in the theoretical world where it was widely and correctly implemented was a major problem. Hence the “ivory tower” comment upthread.
  - geezerjay 7y ago
    The expression "ivory tower" has an entirely different meaning. Just because the couple of dominant players chose to ignore a standard, particularly in a time and age where they were outright hostile to interoperability initiatives, it doesn't mean the standard was not reasonable.
- cygx 7y ago
  What good is a standard you can't use in practice? There also were other issues: XHTML was chasing the dream of the semantic, well-formed, machine-readable web, but it didn't do enough to help with pragmatic problems web designers trying to deliver a product actually faced. As much as I like the idea myself from a theoretical perspective, the market had other priorities.
  - thaumasiotes 7y ago

jcranmer 7y ago

This isn't against XHTML 1.1, which was HTML 4.01 shoved into a container of "if it isn't valid XML, display an error page instead;" rather, a lot of the hate is against XHTML 2.0, which decided to rip out HTML features such as forms, frames, most of the old elements such as <b> or <i>, and generally screw compatibility completely. For a reaction from a browser developer, see https://dbaron.org/log/20090707-ex-html https://dbaron.org/log/20090707-ex-html

ChrisSD 7y ago
Ooph yes. I had forgotten how they were rewriting HTML essentially from scratch and this time basing it on XML. In fairness, it wasn't a completely dumb idea as HTML had picked up a lot of warts from its long history and anyway almost no browser implemented the HTML spec as written. The browser wars especially spread a lot of debris across implementations. The temptation to rip it up and start again is very strong with software engineers even in the best of circumstances (heck, just ask Google about this). 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.
amyjess 7y ago
XHTML 2.0 also did screwy stuff with MIME types I believe. It required specific MIME types that a lot of browsers at the time didn't support, and because of that most browsers would straight-up refuse to render XHTML 2.0.
- gsnedders 7y ago
  That… wasn't even the screwy stuff. 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).