2 ms·

> This simply is not true. The web moved to an XHTML-like dialect of HTML You're thinking of XHTML 1.1 or XHTML 2. That "XHTML-dialect" that everyone switched

> This simply is not true. The web moved to an XHTML-like dialect of HTML You're thinking of XHTML 1.1 or XHTML 2. That "XHTML-dialect" that everyone switched to was called "XHTML 1.0", which allowed serving as either content type. If you're choosing to nitpick about the fact that most sites published would not have worked if served as application/xhtml+xml, I'd invite you to do a survey of sites currently being served as valid HTML5. It's not even that easy to verify as the Nu validator version in use varies so much depending on where it's hosted (or if it's a local jar), and which iteration of the living standard it conforms to is always ambiguous. Have you tried reading the WHATWG spec diffs? The burden on devs who might like to adhere to any kind of strict automated verification of spec. conformance is now out of the question. With XHTML, even if you were serving non-well-formed XML with a text/html content-type, at least your markup could be trivially checked for conformance by almost any XML parser to see why it's not well-formed. It was actually conceivably viable to put that check into build steps or CI. Serving application/xhtml+xml was a nice to have, but anyone believing that serving XHTML as text/html had no value completely missed the point. At least now, years later, the mess we're stuck with should make it a little easier to see though.

hsivonen 9y ago
> If you're choosing to nitpick about the fact that most sites published would not have worked if served as application/xhtml+xml, I'd invite you to do a survey of sites currently being served as valid HTML5. Completely different thing. XML processing and all reasoning based on the premise of XML processing are fiction when XHTML is served as text/html. The HTML parsing algorithm and tve rest of the processing requirements is not fiction when HTML is invalid. (Why are we still talking about this in 2018. Sigh.)
- wink 9y ago
  Because someone asked and it explains some of the history quite nicely. FWIW, maybe I'm the 1% but I wrote valid XHTML 1.0 for a while, but also soon gave up :P
  - Semaphor 9y ago
    I did server side browser sniffing to give IE the version it understood (IIRC it couldn't handle well-formed XHTML served with the proper mime tag, not sure, it's been a while :D) while everything else got proper fully compliant XHTML. I'm pretty sure I used a code snippet from Anne van Kesteren who is also posting here ;)
jerf 9y ago
OK, so by lucideer's quirky definition of "XHTML", the vast majority of the web moved to XHTML. Based on the expansiveness of lucideer's definition, this appear to have encompassed web developers who probably weren't even aware they were writing "XHTML". By the definition that most of us are using, which is that XHTML is complaint XHTML that could be rendered without error in browser's XHTML modes, to a first approximation nobody ever did it. Even today XHTML-levels of precision in HTML requires an awful lot of API support and very careful usage; doing it ten years ago was above almost everybody's skill level.
- lucideer 9y ago
  > by lucideer's quirky definition Which also happens to be the definition the w3c xhtml 1.0 spec. You can choose to think that's quirky, please don't attribute it to me. > definition that most of us are using, which is that XHTML is complaint XHTML that could be rendered without error in browser's XHTML modes Which, again, is the definition used in the later w3c xhtml 1.1 & 2 specs, the former which wasn't widely used, the latter which was abandoned without being published at all. If your issue with XHTML was that W3C were moving towards a direction you disagreed with, then you don't have an issue with the version of XHTML that was in popular use. > XHTML-levels of precision in HTML requires an awful lot of API support and very careful usage I'm not really sure where this view comes from. HTML validation is a lot more complex and difficult to achieve than XML well formedness, and HTML4/XHTML1 validation were both far simpler than modern HTML5 validation (the Nu validator is inordinately complex in comparison to the older DTD one). Furthermore, dev tools for ensuring XML well-formedness are far more readily available and integrated into most things even today, while HTML5 validation is such an obscure concept today I'm sure many devs don't even know it's a thing.
  - ubernostrum 9y ago
    Which also happens to be the definition the w3c xhtml 1.0 spec. You can choose to think that's quirky, please don't attribute it to me. Except that the number of people who actually implemented valid, well-formed, properly-served XHTML Strict -- of any version -- in compliance with all the relevant specifications is at best vanishingly tiny. XHTML Transitional was tag soup. Your retort further up about many sites serving invalid HTML5 actually works against you, since HTML5 explicitly has a forgiving parsing model, while XHTML is explicitly "every error is a fatal error". If browsers had enforced the XHTML approach on every document using an XHTML DOCTYPE, we would have seen the death of XHTML much earlier. This is why people say XHTML was never really adopted -- many people certainly put a "/>" to close their empty elements, and stuck an XML prolog and an XHTML DOCTYPE up at the top, but surveys like the infamous "XHTML 100" showed that next to nobody actually adopted XHTML in a manner compliant with the relevant standards. And I say this as someone who, way back in the early 00's, was serving valid, well-formed XHTML as application/xhtml+xml. XHTML was a terrible approach, and the W3C process was dragging farther and farther from practicality at every revision (remember XHTML 2.0?).

hsivonen 9y ago

> If you're choosing to nitpick about the fact that most sites published would not have worked if served as application/xhtml+xml, I'd invite you to do a survey of sites currently being served as valid HTML5. Completely different thing. XML processing and all reasoning based on the premise of XML processing are fiction when XHTML is served as text/html. The HTML parsing algorithm and tve rest of the processing requirements is not fiction when HTML is invalid. (Why are we still talking about this in 2018. Sigh.)

wink 9y ago
Because someone asked and it explains some of the history quite nicely. FWIW, maybe I'm the 1% but I wrote valid XHTML 1.0 for a while, but also soon gave up :P
- Semaphor 9y ago
  I did server side browser sniffing to give IE the version it understood (IIRC it couldn't handle well-formed XHTML served with the proper mime tag, not sure, it's been a while :D) while everything else got proper fully compliant XHTML. I'm pretty sure I used a code snippet from Anne van Kesteren who is also posting here ;)

jerf 9y ago

OK, so by lucideer's quirky definition of "XHTML", the vast majority of the web moved to XHTML. Based on the expansiveness of lucideer's definition, this appear to have encompassed web developers who probably weren't even aware they were writing "XHTML". By the definition that most of us are using, which is that XHTML is complaint XHTML that could be rendered without error in browser's XHTML modes, to a first approximation nobody ever did it. Even today XHTML-levels of precision in HTML requires an awful lot of API support and very careful usage; doing it ten years ago was above almost everybody's skill level.

lucideer 9y ago
> by lucideer's quirky definition Which also happens to be the definition the w3c xhtml 1.0 spec. You can choose to think that's quirky, please don't attribute it to me. > definition that most of us are using, which is that XHTML is complaint XHTML that could be rendered without error in browser's XHTML modes Which, again, is the definition used in the later w3c xhtml 1.1 & 2 specs, the former which wasn't widely used, the latter which was abandoned without being published at all. If your issue with XHTML was that W3C were moving towards a direction you disagreed with, then you don't have an issue with the version of XHTML that was in popular use. > XHTML-levels of precision in HTML requires an awful lot of API support and very careful usage I'm not really sure where this view comes from. HTML validation is a lot more complex and difficult to achieve than XML well formedness, and HTML4/XHTML1 validation were both far simpler than modern HTML5 validation (the Nu validator is inordinately complex in comparison to the older DTD one). Furthermore, dev tools for ensuring XML well-formedness are far more readily available and integrated into most things even today, while HTML5 validation is such an obscure concept today I'm sure many devs don't even know it's a thing.
- ubernostrum 9y ago
  Which also happens to be the definition the w3c xhtml 1.0 spec. You can choose to think that's quirky, please don't attribute it to me. Except that the number of people who actually implemented valid, well-formed, properly-served XHTML Strict -- of any version -- in compliance with all the relevant specifications is at best vanishingly tiny. XHTML Transitional was tag soup. Your retort further up about many sites serving invalid HTML5 actually works against you, since HTML5 explicitly has a forgiving parsing model, while XHTML is explicitly "every error is a fatal error". If browsers had enforced the XHTML approach on every document using an XHTML DOCTYPE, we would have seen the death of XHTML much earlier. This is why people say XHTML was never really adopted -- many people certainly put a "/>" to close their empty elements, and stuck an XML prolog and an XHTML DOCTYPE up at the top, but surveys like the infamous "XHTML 100" showed that next to nobody actually adopted XHTML in a manner compliant with the relevant standards. And I say this as someone who, way back in the early 00's, was serving valid, well-formed XHTML as application/xhtml+xml. XHTML was a terrible approach, and the W3C process was dragging farther and farther from practicality at every revision (remember XHTML 2.0?).