4 ms·

I used to hate the W3C for wasting everybody's time with XHTML2, which was pretty much known to be dead on arrival from day one because browsers were barely eve

by pluma 9y ago

I used to hate the W3C for wasting everybody's time with XHTML2, which was pretty much known to be dead on arrival from day one because browsers were barely even supporting XHTML (no, accepting XHTML and treating it as HTML tag soup doesn't count as support). About the only browser fully supporting XHTML was Firefox and authors hated it because the spec also demanded a yellow page of death if the XHTML had any syntax errors. WHATWG promised to end this ivory tower nonsense by putting the vendors before academic purity and authors before vendors and users before authors. This sounded like a great idea, but sadly recently it seems that Google has become the de facto ruler of WHATWG and "users" means "users of the Google Chrome browser", putting vendor interests above all. Others elsewhere have already decried WHATWG's flippant attitude to accessibility, ignoring established screenreader best practices and advice from accessibility experts. WHATWG is not altruistic. If W3C is too academic, WHATWG is too commercial.

LaGrange 9y ago
"About the only browser fully supporting XHTML was Firefox and authors hated it because the spec also demanded a yellow page of death if the XHTML had any syntax errors." And this, kids, is why the Internet is, and always will be, such a mess. That was, and always will be, the correct approach to pages with syntax errors. Everywhere else trying to silently 'fix' syntax errors was soundly rejected as a source of innumerable bugs, but on WWW they are treated like line noise.
- pluma 9y ago
  Sure, this is a case where change could have only happened if everybody else joined in at the same time. If you're the only browser to correctly implement the syntax requirements of XML for XHTML: * all existing sites are broken because they're not XHTML but HTML * any "working" XHTML page might break because the author didn't test in your browser * any CMS-based website might break randomly because a content writer used broken markup or used the WYSIWYG editor in a non-compliant browser * any CMS-based website might break randomly because the developers forgot about some edge case that results in bad markup Not to mention that even if you somehow manage to radicalise every other browser vendor to the point where they implement XHTML with yellow pages of death (and also remove HTML support to force authors to migrate) you still only have well-formedness guarantees but the markup itself might still be nonsense or semantically invalid. But pointing and laughing is frankly disingenuous. Though the problem is inherently unsolvable (just ask any programmer using a typed language whether they trust code just because it compiles without errors) not having certain checks at the infrastructure level doesn't prevent developers from writing correct and maintainable code if they chose to and understand how. The reason the web was so full of shitty code for most of its existence is that "real developers" didn't take it seriously and refused to learn the technologies. So the majority of code was written by people who either didn't care to understand what they were doing or had no programming experience (because "real programmers" deemed it unworthy of their expertise). And finally, the reason WHATWG's HTML revision was so well-received was primarily that it also defined appropriate error handling for real-world situations. The W3C spec on the other hand ignored the possibility of errors, leaving these decisions up to the vendors (who had a vested interest in making sure all sites "work").
  - LaGrange 9y ago
    "Sure, this is a case where change could have only happened if everybody else joined in at the same time." If the US wasn't taken over by the free market capitalists for the last 30 years, this would be a solved problems. You can't use a non-conforming browsers to do online shopping. Done. "just ask any programmer using a typed language whether they trust code just because it compiles without errors" This is misconstruing the benefit. This prevents a wide class of errors, and a good type system _assists_ in providing generally good designs. Other than the Haskell people not many claim it magically produces correct code. "not having certain checks at the infrastructure level doesn't prevent developers from writing correct and maintainable code if they chose to and understand how." Neglecting such checks is a fairly good indicator of a bad programmer, though. It's like someone might manage a landing while muting the tower, disabling instruments and putting on a blind fold, but shouldn't expect to keep their job afterwards. "The reason the web was so full of shitty code for most of its existence is that "real developers" didn't take it seriously and refused to learn the technologies." And frankly, it was a pretty sensible choice, it was pretty clear that the politics of the time were stacked up against them. The same sense that tells people to use the safety mechanisms tells them to not fight losing fights. "And finally, the reason WHATWG's HTML revision was so well-received was primarily that it also defined appropriate error handling for real-world situations." No, WHATWG was well received because of a better, more approachable documentation style, significantly better marketing, and good short-term results to reinforce that marketing. W3Cs complete paralysis didn't help.
- tannhaeuser 9y ago
  The choice wasn't unconstrained tag-soup markup vs XML. HTML was originally spec'd using SGML, and SGML is a proper superset of XML. However, reporting the exact place of an error in a large SGML document in the presence of tag inference/omission is challenging or outright impossible. So W3C spent a significant amount of work to bring forward XML as a simplified SGML subset starting in 1997, with the intention that XML eventually replaces SGML as the basis for HTML. Obviously that didn't happen; but that's no reason to give up on structured markup altogether. SGML is perfectly capable to validate and canonicalize almost all HTML 5 documents (save for a few not-so-well-thought-out design decisions from the Hickson era). The same can't be said for the "official" HTML5 validator; even the specification text itself contains content model errors.
om2 9y ago
WHATWG is now led by a Steering Group of the four major browser engine vendors, and for some time has had a rule that every new feature in HTML needs a test suite and implementation commitments from multiple vendors before it can go in. It’s definitely not right to claim it’s controlled by Google.
- marcoperaza 9y ago
  They can have all the formal procedures that they want, but none of them are legally committed to implementing the WHATWG spec. So it ultimately comes down to power, your share of the browsing market[1]. Everything else is ultimately a facade, that will crumble if it diverges too far from the underlying reality. [1] The power of the different vendors isn't a straightforward function of market-share of course, you have to factor in: shares on the different form factors, shares that are locked in (e.g. WebKit on iOS, Blink on ChromeOS), spending habits of the different user bases, etc.
rvern 9y ago
Why blame the W3C for developing XHTML 2 instead of blaming the browsers for not implementing it? XHTML 2 was the way to the Semantic Web. The point was to get rid of JavaScript, extend HTML and CSS and eventually replace them by XSLT and semantic open machine-readable (XML) data formats. The outcome would have been for web browsers to become mere document readers and everything else to be done with native applications able to read and work with interoperable formats. This would have given authors less control, browsers less power (and market share, if web pages did break), and advertisers less revenue. HTML5 was the way to the web as a virtual machine for web applications, which gave authors increased control, advertisers full reign over users' web browsers, and an ever more complicated and resource-hungry web platform[1] tolerant of any web page however bad its code. In hindsight the theoretical purity would have had real benefits for real users. From the HTML Design Principles:[2] > In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once. Theoretical purity is listed at the end as if theoretical purity had nothing to do with the users' interests. The wording makes it seem as if users cared about nothing but "costs or difficulties" (think about the poor users who will have "difficulties" if web pages break!). Nowadays the W3C (EME) and WHATWG are both enmeshed in commercial interests and the organizations left that publish web and document standards are OASIS (which publishes the OpenDocument and DocBook standards) and the IETF. [1]: https://platform.html5.org/ https://platform.html5.org/ [2]: https://www.w3.org/TR/html-design-principles/#priority-of-constituencies https://www.w3.org/TR/html-design-principles/#priority-of-co...

by pluma 9y ago

LaGrange 9y ago

"About the only browser fully supporting XHTML was Firefox and authors hated it because the spec also demanded a yellow page of death if the XHTML had any syntax errors." And this, kids, is why the Internet is, and always will be, such a mess. That was, and always will be, the correct approach to pages with syntax errors. Everywhere else trying to silently 'fix' syntax errors was soundly rejected as a source of innumerable bugs, but on WWW they are treated like line noise.

pluma 9y ago
Sure, this is a case where change could have only happened if everybody else joined in at the same time. If you're the only browser to correctly implement the syntax requirements of XML for XHTML: * all existing sites are broken because they're not XHTML but HTML * any "working" XHTML page might break because the author didn't test in your browser * any CMS-based website might break randomly because a content writer used broken markup or used the WYSIWYG editor in a non-compliant browser * any CMS-based website might break randomly because the developers forgot about some edge case that results in bad markup Not to mention that even if you somehow manage to radicalise every other browser vendor to the point where they implement XHTML with yellow pages of death (and also remove HTML support to force authors to migrate) you still only have well-formedness guarantees but the markup itself might still be nonsense or semantically invalid. But pointing and laughing is frankly disingenuous. Though the problem is inherently unsolvable (just ask any programmer using a typed language whether they trust code just because it compiles without errors) not having certain checks at the infrastructure level doesn't prevent developers from writing correct and maintainable code if they chose to and understand how. The reason the web was so full of shitty code for most of its existence is that "real developers" didn't take it seriously and refused to learn the technologies. So the majority of code was written by people who either didn't care to understand what they were doing or had no programming experience (because "real programmers" deemed it unworthy of their expertise). And finally, the reason WHATWG's HTML revision was so well-received was primarily that it also defined appropriate error handling for real-world situations. The W3C spec on the other hand ignored the possibility of errors, leaving these decisions up to the vendors (who had a vested interest in making sure all sites "work").
- LaGrange 9y ago
  "Sure, this is a case where change could have only happened if everybody else joined in at the same time." If the US wasn't taken over by the free market capitalists for the last 30 years, this would be a solved problems. You can't use a non-conforming browsers to do online shopping. Done. "just ask any programmer using a typed language whether they trust code just because it compiles without errors" This is misconstruing the benefit. This prevents a wide class of errors, and a good type system _assists_ in providing generally good designs. Other than the Haskell people not many claim it magically produces correct code. "not having certain checks at the infrastructure level doesn't prevent developers from writing correct and maintainable code if they chose to and understand how." Neglecting such checks is a fairly good indicator of a bad programmer, though. It's like someone might manage a landing while muting the tower, disabling instruments and putting on a blind fold, but shouldn't expect to keep their job afterwards. "The reason the web was so full of shitty code for most of its existence is that "real developers" didn't take it seriously and refused to learn the technologies." And frankly, it was a pretty sensible choice, it was pretty clear that the politics of the time were stacked up against them. The same sense that tells people to use the safety mechanisms tells them to not fight losing fights. "And finally, the reason WHATWG's HTML revision was so well-received was primarily that it also defined appropriate error handling for real-world situations." No, WHATWG was well received because of a better, more approachable documentation style, significantly better marketing, and good short-term results to reinforce that marketing. W3Cs complete paralysis didn't help.
tannhaeuser 9y ago
The choice wasn't unconstrained tag-soup markup vs XML. HTML was originally spec'd using SGML, and SGML is a proper superset of XML. However, reporting the exact place of an error in a large SGML document in the presence of tag inference/omission is challenging or outright impossible. So W3C spent a significant amount of work to bring forward XML as a simplified SGML subset starting in 1997, with the intention that XML eventually replaces SGML as the basis for HTML. Obviously that didn't happen; but that's no reason to give up on structured markup altogether. SGML is perfectly capable to validate and canonicalize almost all HTML 5 documents (save for a few not-so-well-thought-out design decisions from the Hickson era). The same can't be said for the "official" HTML5 validator; even the specification text itself contains content model errors.

om2 9y ago

WHATWG is now led by a Steering Group of the four major browser engine vendors, and for some time has had a rule that every new feature in HTML needs a test suite and implementation commitments from multiple vendors before it can go in. It’s definitely not right to claim it’s controlled by Google.

marcoperaza 9y ago
They can have all the formal procedures that they want, but none of them are legally committed to implementing the WHATWG spec. So it ultimately comes down to power, your share of the browsing market[1]. Everything else is ultimately a facade, that will crumble if it diverges too far from the underlying reality. [1] The power of the different vendors isn't a straightforward function of market-share of course, you have to factor in: shares on the different form factors, shares that are locked in (e.g. WebKit on iOS, Blink on ChromeOS), spending habits of the different user bases, etc.

rvern 9y ago

Why blame the W3C for developing XHTML 2 instead of blaming the browsers for not implementing it? XHTML 2 was the way to the Semantic Web. The point was to get rid of JavaScript, extend HTML and CSS and eventually replace them by XSLT and semantic open machine-readable (XML) data formats. The outcome would have been for web browsers to become mere document readers and everything else to be done with native applications able to read and work with interoperable formats. This would have given authors less control, browsers less power (and market share, if web pages did break), and advertisers less revenue. HTML5 was the way to the web as a virtual machine for web applications, which gave authors increased control, advertisers full reign over users' web browsers, and an ever more complicated and resource-hungry web platform[1] tolerant of any web page however bad its code. In hindsight the theoretical purity would have had real benefits for real users. From the HTML Design Principles:[2] > In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once. Theoretical purity is listed at the end as if theoretical purity had nothing to do with the users' interests. The wording makes it seem as if users cared about nothing but "costs or difficulties" (think about the poor users who will have "difficulties" if web pages break!). Nowadays the W3C (EME) and WHATWG are both enmeshed in commercial interests and the organizations left that publish web and document standards are OASIS (which publishes the OpenDocument and DocBook standards) and the IETF. [1]: https://platform.html5.org/ https://platform.html5.org/ [2]: https://www.w3.org/TR/html-design-principles/#priority-of-constituencies https://www.w3.org/TR/html-design-principles/#priority-of-co...