3 ms·

No, it wasn't simply a question of backwards compatibility. The W3C wanted (wants?) to pursue its own quixotic vision of a semantic, machine-readable web. One i

No, it wasn't simply a question of backwards compatibility. The W3C wanted (wants?) to pursue its own quixotic vision of a semantic, machine-readable web. One in which the needs of human users, browser user agents and use cases like web apps was of incidental importance at best. The HTML5 spec effort that gave birth to WHATWG wasn't simply about documenting backwards compatible parsing, it was about vendors like Mozilla and Opera wanting to evolve HTML in a way that added actually useful new features, something that W3C had zero interest in at the time. Nowadays, the W3C's behaviour seems to be driven entirely by an institutional desire to justify its own existence, and protect its revenue stream and its self-assumed position as the one-true source of web standards, by engaging in bad-faith practices like taking standards produced through the hard work of others, removing all citations, making breaking changes, and publishing it as a competing "standard".

kuschku 9y ago
Yes, and today we’re left with a web that you can only parse if you’ve got a few thousand developers and billions of dollars to throw at the issue. As I wrote below, I offer $100 to anyone that can write a tool that can fully parse and render HTML5, the entire spec, and can a real-life React app, within of 4 weeks, without using any existing library or code for the parsing or rendering. Doing the same for XHTML and a strict scripting language is easily possible in that time.
- stupidcar 9y ago
  That was the situation prior to the writing of the HTML5 spec, not a situation it created. The majority of the web was not, and never would have been parsable as strict XHTML, whatever the desire of the W3C or anybody else. And even for new content, the idea that every hand-authored file would be well-formed, or that every half-baked and buggy CMS would always produce correct markup was a pipe-dream. If strict parsing had been enforced, we'd have a web where a large proportion of the sites you visited each day would be broken. Or rather, we wouldn't, because complaints from users would have long ago forced browser vendors to implement graceful error handling, and so you'd end up with something akin to HTML5 anyway. Indeed, it was encountering precisely this problem that made vendors like Mozilla and Opera (who, incidentally, never had billions of dollars) to lose faith in XHTML in the first place, not some masochistic desire to keep their browsers' code as complicated as possible.
- deleted 9y ago
  [deleted]
- monetus 9y ago
  It would be awesome if the layers of the browser would allow for a more parseable, document-based web. That would be an effort towards standardization. But are you really advocating for removing dynamic media from the browser? That seems like an incredible step backwards in most regards. In the absence of a desktop toolkit to rule them all, browser standardization is what we are left with right?
  - kuschku 9y ago
    > In the absence of a desktop toolkit to rule them all Qt. Runs everywhere, works everywhere, just fine.
    - tptacek 9y ago
      If only some standards group somewhere could mandate that everyone use Qt.
    - monetus 9y ago
      Ah, this gets into gpl vs bsd though doesn't it? I'm not sure what to think about dual licensing. I have a fondness for Qt, but I also like tcl/tk so... its hard not for me to think of that xkcd about standards. https://xkcd.com/927/ https://xkcd.com/927/
- coding123 9y ago
  React probably uses HTML5 APIs but could probably be re-written to do the same thing without them... I'm not sure anyone here is interested in $100 as they probably wasted at least that much "company" money reading this thread this happy Friday.
  - kuschku 9y ago
    The $100 is for someone writing a fully-working parser that handles real-world HTML5 pages, without reusing any existing implementations. Building an entire new parser is (obviously) much easier for strict languages (e.g. JSON) than for lenient languages (e.g. HTML5). Which is the problem I have with HTML5, JS, and many similar technologies – they’re so lenient that almost everything is broken instead. We might as well write websites in english prose, it wouldn’t be much harder to parse.

kuschku 9y ago

Yes, and today we’re left with a web that you can only parse if you’ve got a few thousand developers and billions of dollars to throw at the issue. As I wrote below, I offer $100 to anyone that can write a tool that can fully parse and render HTML5, the entire spec, and can a real-life React app, within of 4 weeks, without using any existing library or code for the parsing or rendering. Doing the same for XHTML and a strict scripting language is easily possible in that time.

stupidcar 9y ago
That was the situation prior to the writing of the HTML5 spec, not a situation it created. The majority of the web was not, and never would have been parsable as strict XHTML, whatever the desire of the W3C or anybody else. And even for new content, the idea that every hand-authored file would be well-formed, or that every half-baked and buggy CMS would always produce correct markup was a pipe-dream. If strict parsing had been enforced, we'd have a web where a large proportion of the sites you visited each day would be broken. Or rather, we wouldn't, because complaints from users would have long ago forced browser vendors to implement graceful error handling, and so you'd end up with something akin to HTML5 anyway. Indeed, it was encountering precisely this problem that made vendors like Mozilla and Opera (who, incidentally, never had billions of dollars) to lose faith in XHTML in the first place, not some masochistic desire to keep their browsers' code as complicated as possible.
deleted 9y ago
[deleted]
monetus 9y ago
It would be awesome if the layers of the browser would allow for a more parseable, document-based web. That would be an effort towards standardization. But are you really advocating for removing dynamic media from the browser? That seems like an incredible step backwards in most regards. In the absence of a desktop toolkit to rule them all, browser standardization is what we are left with right?
- kuschku 9y ago
  > In the absence of a desktop toolkit to rule them all Qt. Runs everywhere, works everywhere, just fine.
  - tptacek 9y ago
    If only some standards group somewhere could mandate that everyone use Qt.
  - monetus 9y ago
    Ah, this gets into gpl vs bsd though doesn't it? I'm not sure what to think about dual licensing. I have a fondness for Qt, but I also like tcl/tk so... its hard not for me to think of that xkcd about standards. https://xkcd.com/927/ https://xkcd.com/927/
coding123 9y ago
React probably uses HTML5 APIs but could probably be re-written to do the same thing without them... I'm not sure anyone here is interested in $100 as they probably wasted at least that much "company" money reading this thread this happy Friday.
- kuschku 9y ago
  The $100 is for someone writing a fully-working parser that handles real-world HTML5 pages, without reusing any existing implementations. Building an entire new parser is (obviously) much easier for strict languages (e.g. JSON) than for lenient languages (e.g. HTML5). Which is the problem I have with HTML5, JS, and many similar technologies – they’re so lenient that almost everything is broken instead. We might as well write websites in english prose, it wouldn’t be much harder to parse.