10 ms·

To put a slightly different spin on the same story as perspective always colours the telling: W3C decided to deprecate HTML in favour of XHTML. Most of the web

To put a slightly different spin on the same story as perspective always colours the telling: W3C decided to deprecate HTML in favour of XHTML. Most of the web quickly moved to XHTML. One individual (an employee at Opera, then Mozilla, finally and currently Google) wrote an oddly influential opinion piece saying the the move to XHTML had been somehow harmful and pushed for the major browser vendors to form a rival non-democratic standards body (WHATWG) to the W3C, which forked and completely redefined HTML. The W3C, which unlike the WHATWG has many voting members from many backgrounds, not all related to browser making, quite understandably was never fully on board with the new WHATWG HTML spec efforts. However, with the level of adoption and support it received (mainly from being the creation of the powerful browser vendors) W3C were eventually pressured into conceding to advocate for HTML. Which they've done by maintaining a copy, rather than blindly directing people to the work by what for all intents and purposes effectively amounts to a rival organisation, and an extremely undemocratic one at that. As web developers, we should follow the WHATWG and ignore the W3C, because the W3C have lost the political battle for HTML and we need to get our stuff working on browsers, all of whom follow WHATWG. But that's an unfortunately pragmatic approach that shouldn't amount to acceptance.

tptacek 9y ago
That seems to ignore the conventional wisdom that according-to-Hoyle XHTML was a DOA standard because it mandated error handling in ways that no browser implemented and most of the authoring community didn't want. Authors don't write well-formed XML, even today.
- anonymfus 9y ago
  >because it mandated error handling in ways that no browser implemented IIRC Opera implemented XHTML error handling.
  - kalleboo 9y ago
    IIRC several major browsers implemented XHTML error handling, but only for documents with a Content-Type: application/xhtml+xml header, which was basically nothing because that would then trip up other browsers
  - rimliu 9y ago
    Opera had the "draconical" approach, where upon the error you just had that, an error. Firefox, iirc had a softer approach where you still got the page rendered, but you'd get the error reported too. Anyway it all depended on the proper MIME type for the XTHML (as it should). However the whole MIME type and everything associated with it (some elements and APIs are treated differently) is a whole barrel of worms, so XHTML in any of the incarnations was never a good idea.
    - winkeltripel 9y ago
      > "draconical" That's xml error handling, following rules as written.
      - tptacek 9y ago
        "Draconian" error handling is a term of art in HTML.
- lucideer 9y ago
  > it mandated error handling XHTML 1.0 didn't mandate so-called "draconian error-handling", it just offered it as an optional feature. XHTML 1.1 (which was released but noone used) and XHTML 2 (which was never finished nor released) did mandate it. I wasn't a big fan of that decision, I don't think it would've worked, but XHTML 1.1 was still very usable while ignoring that one requirement; throwing out the baby with the bath water was a massive overreaction on the WHATWG's part.
  - ubernostrum 9y ago
    XHTML, other than Transitional, which nobody should count as "implementing XHTML", is an XML application. It inherits XML's parsing model. Every error is a fatal error.
ChrisSD 9y ago
I'm not certain that it's true to say most of the web quickly moved to XHTML. Sure a number of sites advertised themselves as XHTML but they were not strictly XHTML compliant. This could be due to third party widgets or other included code or it could be due to a mistake in template construction. Whatever the issue fully compliant XHTML wasn't used much in practice outside of hand-crafted pages. Also Internet Explorer, for example, never implemented XHTML which would have been a deal breaker for many sites.
- lucideer 9y ago
  > they were not strictly XHTML compliant The vast majority were not strictly XHTML compliant, but whatever the figure was, I'd imagine it wasn't too different to all the many "strictly HTML compliant" sites now (compliant according to which commit?). The point was they used XHTML, which means they could trivially choose to validate and test their XML well-formedness with built-in tools everyone had ready access to. Exposing your end-users to those conformance checks (i.e. the in-browser strict XML-parser) wasn't the only "value" offered.
  - ubernostrum 9y ago
    The point was they used XHTML, which means they could trivially choose to validate and test their XML well-formedness with built-in tools everyone had ready access to. I'm honestly trying to figure out whether this is satire or not.
Hello71 9y ago
> Most of the web quickly moved to XHTML Ridiculous and absurd. A small proportion of the web moved to invalid XHTML that rendered as tag soup because it was sent as text/html. Virtually no websites actually served XHTML as XHTML, because: 1. there were and still are no compelling technical benefits of XHTML, 2. it broke Internet Explorer, 3. most webmasters were and still are incompetent and have no clue what Content-Type is.
colanderman 9y ago
> not all related to browser making, quite understandably was never fully on board with the new WHATWG HTML spec efforts. That's the other thing that pisses me off about the WHATWG, is how much they shit all over XML and other interoperability technologies. E.g. their URL standard (because, why not fuck the IETF as well) basically ignores anything non-HTTP for specious reasons.
- bzbarsky 9y ago
  The only reason there is a URL standard in the WHATWG is that the IETF URL RFC didn't define error handling and this led to interop problems. So there was a need for a URL standard that _would_ define error handling. The IETF refused to produce one (basically said "fuck you, we don't care about your use cases or interop problems" with slightly more polite wording), so the WHATWG ended up doing it... I'm not saying this is a great situation. I'm not saying the WHATWG couldn't try to do better at considering non-HTTP or non-browser use cases here. But the representatives of those use cases in the IETF told browsers to take a hike. And then browsers did.
  - kuschku 9y ago
    The first line of the WHATWG URL spec says that it deprecates and replaces all IETF URL standards.
    - bzbarsky 9y ago
      For its target audience (browsers and web pages) it does.
- annevk 9y ago
  What do you mean by non-HTTP? It handles URLs whose scheme is not http(s): just fine...
  - colanderman 9y ago
    I forget the specifics, but there are several incompatibilities between the IETF URI and IRI spec and the WHATWG URL spec (see [1], EDIT: as I'm sure you're well aware, given your username). The WHATWG spec amounts to "what four popular web browsers do", explicitly without considering compatibility with the hundreds (thousands?) of other non-web-browser tools that make use of URIs. What you've defined are effectively not URLs. Very similar, but different. If you wanted to call them "WHATWGRLs" or something I wouldn't care. But they're not URLs, and the WHATWG is choosing to muddy the waters rather than, say, specify an optional legacy compatibility layer on top of the IETF spec. It's one thing to say "in addition to IETF URIs, browsers should also accept these malformed URIs, but should not accept these valid but problematic URIs"… it's quite another to say "URIs aren't that anymore, now they're this". [1] https://daniel.haxx.se/blog/2016/05/11/my-url-isnt-your-url/ https://daniel.haxx.se/blog/2016/05/11/my-url-isnt-your-url/
Sharlin 9y ago
> Most of the web quickly moved to XHTML. This simply is not true. The web moved to an XHTML-like dialect of HTML which was still served as text/html and browsers interpreted it as "HTML soup" because actually serving pages as application/xhtml+xml would have broken the majority of the web because browsers would actually validate them and refuse to display a page at all if there was even a single missing close tag.
- xtian 9y ago
  And the versions of IE in use didn’t support application/xhtml+xml anyway so you would have to switch to text/html based on the user agent string. It was never clear what the technical benefit of this was supposed to be. I only ever saw one site whose pages served double duty as an API and UI by serving styled XML. It seemed like a challenging approach to pull off well.
  - chias 9y ago
    The Gentoo website / handbook does this. Or rather, did this a few years ago when I was last messing around with Gentoo. It seems to be HTML now.
    - Hello71 9y ago
      The Handbook was interesting in that it was one of the few sites that actually went with the XML + XSLT = XHTML route. Of course, nobody knows XSLT, and everyone hates XML, so it was dumped in favor of MediaWiki, which everyone still hates, but at least now mostly understands how to use. (although the same people that insisted we use XML+XSLT also insisted we use SMW, which is even worse... I gave up then, but I hear they're trying to undo SMW now.)
      - chias 9y ago
        Interesting! What's SMW? I'm not familiar with the term and searching for it isn't being particularly helpful.
coldtea 9y ago
>W3C decided to deprecate HTML in favour of XHTML. Most of the web quickly moved to XHTML. In some parallel universes, yes. Even if so, there's also the fact that XHTML wasn't updated itself with features people needed.
- lucideer 9y ago
  What features? If you're referring to "features" in the HTML5 spec., like canvas, webgl, geolocation, DOM etc. they were separate specs, which WHATWG lumped into one monolith (though they're mainly JavaScript APIs, and aren't directly related to HTML). They were being worked on separately to XHTML, and still work fine with XHTML to this day.
  - coldtea 9y ago
    >they were separate specs, which WHATWG lumped into one monolith For which I could not care less. Whether there's a big spec for HTML5+JS APIs, or 20 different specs, is a bureaucratic concern, not a concern to the developers or the end users. W3C might had them "neatly" separated, by it also haven't moved them notch towards completion and release for more than a decade. I've used and worked for the web before W3C, in its heyday, in its long decline days when we waiting a decade+ for some progress, and after it become irrelevant. Now it's a way better situation.
lambda 9y ago
> Most of the web quickly moved to XHTML. Most of the web didn't move to XHTML. A lot of people who were interested in being standards compliant moved to XHTML 1.0 Transitional, which was the HTML compatibility subset, but they only ever served it and validated it as HTML, not XHTML, because if you served it as XHTML, one single stray < that someone had forgotten to quote somewhere would break the parsing of the whole page. The piece written by Hixie was influential because it was a wake up call that the direction the standards bodies were going in was pretty much fruitless, and that there could be a much better way to do it which wouldn't involve breaking compatibility with all of the existing content and would give web developers and users features that they actually wanted. > As web developers, we should follow the WHATWG and ignore the W3C, because the W3C have lost the political battle for HTML and we need to get our stuff working on browsers, all of whom follow WHATWG. But that's an unfortunately pragmatic approach that shouldn't amount to acceptance. I fail to see how there is anything unfortunate about this. What about rewriting everything in XHTML 2.0 (https://www.w3.org/TR/2010/NOTE-xhtml2-20101216/ https://www.w3.org/TR/2010/NOTE-xhtml2-20101216/), and having to be extremely conscious of any possible stray < that could sneak in to a page without being quoted, would have been preferable to: 1. Consistent parsing support for existing content, and content that might have slight problems like stray <, in all browsers 2. Standardization of things that people actually use to build web apps, like XMLHttpRequest and Canvas 3. Consistent handling of encodings between browsers, including encoding sniffing 4. Consistent handling of quirks mode vs. standards mode between browsers 5. Actually having browsers support compatibility with vendor-prefixed versions of features, because some browsers widely used introduced prefixed features that web developers actually started relying upon And also, have you ever tried getting involved with the WHATWG process? I have, and I find that they are very receptive to intelligent discussion of issues. What doesn't work well is to insist that you have a problem and that this particular solution must be used to address the problem; because a lot of times, it's easy to come up with some proposed solution but it then turns out that it's either a lot more complex in practice, your proposal does't fit in with the rest of the ecosystem well, or the problem can actually be solve just in tooling on top of HTML without having to change the spec at all and then wait for multiple browser vendors to all independently implement it.
- tathougies 9y ago
fjsolwmv 9y ago
That particular person is longtime leading advocate for "humanitarian eugenics" for promoting the "advancement of civilization", so undemocratic elitism in web standards is fitting with their overall worldview.
dragonwriter 9y ago
> Most of the web quickly moved to XHTML No, it didn't. At best a large share of new, greenfield development moved to XHTML, but I'm not convinced it was a majority of even that.

tptacek 9y ago

That seems to ignore the conventional wisdom that according-to-Hoyle XHTML was a DOA standard because it mandated error handling in ways that no browser implemented and most of the authoring community didn't want. Authors don't write well-formed XML, even today.

anonymfus 9y ago
>because it mandated error handling in ways that no browser implemented IIRC Opera implemented XHTML error handling.
- kalleboo 9y ago
  IIRC several major browsers implemented XHTML error handling, but only for documents with a Content-Type: application/xhtml+xml header, which was basically nothing because that would then trip up other browsers
- rimliu 9y ago
  Opera had the "draconical" approach, where upon the error you just had that, an error. Firefox, iirc had a softer approach where you still got the page rendered, but you'd get the error reported too. Anyway it all depended on the proper MIME type for the XTHML (as it should). However the whole MIME type and everything associated with it (some elements and APIs are treated differently) is a whole barrel of worms, so XHTML in any of the incarnations was never a good idea.
  - winkeltripel 9y ago
    > "draconical" That's xml error handling, following rules as written.
    - tptacek 9y ago
      "Draconian" error handling is a term of art in HTML.
lucideer 9y ago
> it mandated error handling XHTML 1.0 didn't mandate so-called "draconian error-handling", it just offered it as an optional feature. XHTML 1.1 (which was released but noone used) and XHTML 2 (which was never finished nor released) did mandate it. I wasn't a big fan of that decision, I don't think it would've worked, but XHTML 1.1 was still very usable while ignoring that one requirement; throwing out the baby with the bath water was a massive overreaction on the WHATWG's part.
- ubernostrum 9y ago
  XHTML, other than Transitional, which nobody should count as "implementing XHTML", is an XML application. It inherits XML's parsing model. Every error is a fatal error.

ChrisSD 9y ago

I'm not certain that it's true to say most of the web quickly moved to XHTML. Sure a number of sites advertised themselves as XHTML but they were not strictly XHTML compliant. This could be due to third party widgets or other included code or it could be due to a mistake in template construction. Whatever the issue fully compliant XHTML wasn't used much in practice outside of hand-crafted pages. Also Internet Explorer, for example, never implemented XHTML which would have been a deal breaker for many sites.

lucideer 9y ago
> they were not strictly XHTML compliant The vast majority were not strictly XHTML compliant, but whatever the figure was, I'd imagine it wasn't too different to all the many "strictly HTML compliant" sites now (compliant according to which commit?). The point was they used XHTML, which means they could trivially choose to validate and test their XML well-formedness with built-in tools everyone had ready access to. Exposing your end-users to those conformance checks (i.e. the in-browser strict XML-parser) wasn't the only "value" offered.
- ubernostrum 9y ago
  The point was they used XHTML, which means they could trivially choose to validate and test their XML well-formedness with built-in tools everyone had ready access to. I'm honestly trying to figure out whether this is satire or not.

Hello71 9y ago

> Most of the web quickly moved to XHTML Ridiculous and absurd. A small proportion of the web moved to invalid XHTML that rendered as tag soup because it was sent as text/html. Virtually no websites actually served XHTML as XHTML, because: 1. there were and still are no compelling technical benefits of XHTML, 2. it broke Internet Explorer, 3. most webmasters were and still are incompetent and have no clue what Content-Type is.

colanderman 9y ago

> not all related to browser making, quite understandably was never fully on board with the new WHATWG HTML spec efforts. That's the other thing that pisses me off about the WHATWG, is how much they shit all over XML and other interoperability technologies. E.g. their URL standard (because, why not fuck the IETF as well) basically ignores anything non-HTTP for specious reasons.

bzbarsky 9y ago
The only reason there is a URL standard in the WHATWG is that the IETF URL RFC didn't define error handling and this led to interop problems. So there was a need for a URL standard that _would_ define error handling. The IETF refused to produce one (basically said "fuck you, we don't care about your use cases or interop problems" with slightly more polite wording), so the WHATWG ended up doing it... I'm not saying this is a great situation. I'm not saying the WHATWG couldn't try to do better at considering non-HTTP or non-browser use cases here. But the representatives of those use cases in the IETF told browsers to take a hike. And then browsers did.
- kuschku 9y ago
  The first line of the WHATWG URL spec says that it deprecates and replaces all IETF URL standards.
  - bzbarsky 9y ago
    For its target audience (browsers and web pages) it does.
annevk 9y ago
What do you mean by non-HTTP? It handles URLs whose scheme is not http(s): just fine...
- colanderman 9y ago
  I forget the specifics, but there are several incompatibilities between the IETF URI and IRI spec and the WHATWG URL spec (see [1], EDIT: as I'm sure you're well aware, given your username). The WHATWG spec amounts to "what four popular web browsers do", explicitly without considering compatibility with the hundreds (thousands?) of other non-web-browser tools that make use of URIs. What you've defined are effectively not URLs. Very similar, but different. If you wanted to call them "WHATWGRLs" or something I wouldn't care. But they're not URLs, and the WHATWG is choosing to muddy the waters rather than, say, specify an optional legacy compatibility layer on top of the IETF spec. It's one thing to say "in addition to IETF URIs, browsers should also accept these malformed URIs, but should not accept these valid but problematic URIs"… it's quite another to say "URIs aren't that anymore, now they're this". [1] https://daniel.haxx.se/blog/2016/05/11/my-url-isnt-your-url/ https://daniel.haxx.se/blog/2016/05/11/my-url-isnt-your-url/

Sharlin 9y ago

> Most of the web quickly moved to XHTML. This simply is not true. The web moved to an XHTML-like dialect of HTML which was still served as text/html and browsers interpreted it as "HTML soup" because actually serving pages as application/xhtml+xml would have broken the majority of the web because browsers would actually validate them and refuse to display a page at all if there was even a single missing close tag.

xtian 9y ago
And the versions of IE in use didn’t support application/xhtml+xml anyway so you would have to switch to text/html based on the user agent string. It was never clear what the technical benefit of this was supposed to be. I only ever saw one site whose pages served double duty as an API and UI by serving styled XML. It seemed like a challenging approach to pull off well.
- chias 9y ago
  The Gentoo website / handbook does this. Or rather, did this a few years ago when I was last messing around with Gentoo. It seems to be HTML now.
  - Hello71 9y ago
    The Handbook was interesting in that it was one of the few sites that actually went with the XML + XSLT = XHTML route. Of course, nobody knows XSLT, and everyone hates XML, so it was dumped in favor of MediaWiki, which everyone still hates, but at least now mostly understands how to use. (although the same people that insisted we use XML+XSLT also insisted we use SMW, which is even worse... I gave up then, but I hear they're trying to undo SMW now.)
    - chias 9y ago
      Interesting! What's SMW? I'm not familiar with the term and searching for it isn't being particularly helpful.

coldtea 9y ago

>W3C decided to deprecate HTML in favour of XHTML. Most of the web quickly moved to XHTML. In some parallel universes, yes. Even if so, there's also the fact that XHTML wasn't updated itself with features people needed.

lucideer 9y ago
What features? If you're referring to "features" in the HTML5 spec., like canvas, webgl, geolocation, DOM etc. they were separate specs, which WHATWG lumped into one monolith (though they're mainly JavaScript APIs, and aren't directly related to HTML). They were being worked on separately to XHTML, and still work fine with XHTML to this day.
- coldtea 9y ago
  >they were separate specs, which WHATWG lumped into one monolith For which I could not care less. Whether there's a big spec for HTML5+JS APIs, or 20 different specs, is a bureaucratic concern, not a concern to the developers or the end users. W3C might had them "neatly" separated, by it also haven't moved them notch towards completion and release for more than a decade. I've used and worked for the web before W3C, in its heyday, in its long decline days when we waiting a decade+ for some progress, and after it become irrelevant. Now it's a way better situation.

lambda 9y ago

> Most of the web quickly moved to XHTML. Most of the web didn't move to XHTML. A lot of people who were interested in being standards compliant moved to XHTML 1.0 Transitional, which was the HTML compatibility subset, but they only ever served it and validated it as HTML, not XHTML, because if you served it as XHTML, one single stray < that someone had forgotten to quote somewhere would break the parsing of the whole page. The piece written by Hixie was influential because it was a wake up call that the direction the standards bodies were going in was pretty much fruitless, and that there could be a much better way to do it which wouldn't involve breaking compatibility with all of the existing content and would give web developers and users features that they actually wanted. > As web developers, we should follow the WHATWG and ignore the W3C, because the W3C have lost the political battle for HTML and we need to get our stuff working on browsers, all of whom follow WHATWG. But that's an unfortunately pragmatic approach that shouldn't amount to acceptance. I fail to see how there is anything unfortunate about this. What about rewriting everything in XHTML 2.0 (https://www.w3.org/TR/2010/NOTE-xhtml2-20101216/ https://www.w3.org/TR/2010/NOTE-xhtml2-20101216/), and having to be extremely conscious of any possible stray < that could sneak in to a page without being quoted, would have been preferable to: 1. Consistent parsing support for existing content, and content that might have slight problems like stray <, in all browsers 2. Standardization of things that people actually use to build web apps, like XMLHttpRequest and Canvas 3. Consistent handling of encodings between browsers, including encoding sniffing 4. Consistent handling of quirks mode vs. standards mode between browsers 5. Actually having browsers support compatibility with vendor-prefixed versions of features, because some browsers widely used introduced prefixed features that web developers actually started relying upon And also, have you ever tried getting involved with the WHATWG process? I have, and I find that they are very receptive to intelligent discussion of issues. What doesn't work well is to insist that you have a problem and that this particular solution must be used to address the problem; because a lot of times, it's easy to come up with some proposed solution but it then turns out that it's either a lot more complex in practice, your proposal does't fit in with the rest of the ecosystem well, or the problem can actually be solve just in tooling on top of HTML without having to change the spec at all and then wait for multiple browser vendors to all independently implement it.

tathougies 9y ago

fjsolwmv 9y ago

That particular person is longtime leading advocate for "humanitarian eugenics" for promoting the "advancement of civilization", so undemocratic elitism in web standards is fitting with their overall worldview.

dragonwriter 9y ago

> Most of the web quickly moved to XHTML No, it didn't. At best a large share of new, greenfield development moved to XHTML, but I'm not convinced it was a majority of even that.