6 ms·

"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 synta

"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.

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.