4 ms·

> WHATWG's formulation of HTML has deliberately distanced itself from SGML out of ignorance I don't think that's a fair characterization at all. Ian Hickson w

> WHATWG's formulation of HTML has deliberately distanced itself from SGML out of ignorance I don't think that's a fair characterization at all. Ian Hickson was pretty intimately familiar with the SGML formulation of HTML. What led to that being dropped was that no browsers implemented it in practice and that trying to implement it as written in the HTML 4 standard actively broke web pages (which had been written against browsers, not against the spec). Firefox tried going down that route for a while; I should know, because I implemented some parts of that and reviewed the code for the implementations of other parts. We eventually had to remove them, because of compat problems with websites. Comment parsing was a perennial favorite there. > For example, the keygen element has been removed That is a good point, yes. Arguably it should have been left in as a void element with no behavior to avoid parsing issues of the sort you describe... > So tell me why, as an author, I should follow WHATWG's vision for HTML? Honestly, because that's the thing browsers will implement. That's the only reason.

domenicd 7y ago
> That is a good point, yes. Arguably it should have been left in as a void element with no behavior to avoid parsing issues of the sort you describe... That's what we did, actually :). Parsing behavior was unchanged. Ctrl+F "keygen" in https://html.spec.whatwg.org/multipage/parsing.html https://html.spec.whatwg.org/multipage/parsing.html.
- bzbarsky 7y ago
  I should have checked carefully, sorry!
- tannhaeuser 7y ago
  You do realize that spontaneously editing the spec to drop, then re-introduce an element buried in a git commit is exactly the reason why WHATWG is an unreliable source for a definite HTML reference, don't you? Especially when it goes unnoticed even by experts such as GP. At the same time, you want to claim authoritative control over HTML, yet show no sign of respecting other established standards and standard bodies such as ISO/IEC, IETF (eg avk's URL "standard"), and W3C?
  - domenicd 7y ago
    I'm not sure what you mean by drop and then re-introduce, buried in a Git commit. We made a single commit to remove keygen, after displaying a public deprecation-will-be-removed notice in the spec for some years. Dropping keygen was part of a highly-public pull request, which gathered discussion from all browser vendors, as well as interested community members. The pull request was only merged once all four browser vendors supported removal (2 had already removed by that point).
tannhaeuser 7y ago
The narrative that "HTML5 looked at what browsers do, rather than following ivory tower SGML" is simply a myth and not backed up by facts. Ian Hickson introduced sectioning elements, the whole flawed outlining algorithm idea, and the aside element (presumably to make it easier to tell ads from content for Google's crawler), with lots of controversities at the time. The HTML spec is also chock full of inconsistencies of that time and mindset (for example, the allowed characters in ID attributes or general lexical rules for elements not matching CSS selectors' idea of an ID or element name) not actually supported by any browser. Please don't tell me SGML comments were the problem - SGML commenting syntax is straightforward, eg. anything in double-hyphens within a markup declaration is treated as a comment, and there can be multiple comments in a markup declaration (unlike XML). The only problem I see is that there is an interaction with an ancient form of JavaScript comment taking the form of double-hyphens, presumably to make JavaScript commenting uniform with HTML syntax. Now the rules for terminating the content of a script element are dangerously bogus in ancient HTML, but HTML5 has done nothing to fix the situation. In any case, WHATWG has driven almost all web browsers out of existence already; appealing to what "browser vendors" (Google) actually do is not the solution, but part of the problem, obviously.
- om2 7y ago
  The HTML parsing algorithm looked at what browsers do. WHATWG HTML also included other innovations, some of which didn’t entirely work out. Nowadays, new additions are not added so loosely and there is a better defined working mode and governance policy.
  - tannhaeuser 7y ago
    "Government policy" yeah right. Chrome implements stuff, and Moz has to follow suit; then it gets prescribed in WHATWG's spec. OTOH, stuff introduced by Moz that Chrome doesn't implement gets removed from the spec. Such as much needed new elements for basic declarative UIs (menu, menuitem) to fight over-reliance on JavaScript and CSS hacks, introduced by FF but boycotted by Chrome. As was part of the WHATWG snapshot on which W3C HTML 5.1 was based, and removed in W3C HTML 5.2. There's no evidence Hixie analyzed "what browsers were doing". There is, however, evidence that Hixie just made up new elements as he saw fit [1]. [1]: https://www.webdesignerdepot.com/2013/the-harsh-truth-about-html5s-structural-semantics-part-1/ https://www.webdesignerdepot.com/2013/the-harsh-truth-about-...

domenicd 7y ago

> That is a good point, yes. Arguably it should have been left in as a void element with no behavior to avoid parsing issues of the sort you describe... That's what we did, actually :). Parsing behavior was unchanged. Ctrl+F "keygen" in https://html.spec.whatwg.org/multipage/parsing.html https://html.spec.whatwg.org/multipage/parsing.html.

bzbarsky 7y ago
I should have checked carefully, sorry!
tannhaeuser 7y ago
You do realize that spontaneously editing the spec to drop, then re-introduce an element buried in a git commit is exactly the reason why WHATWG is an unreliable source for a definite HTML reference, don't you? Especially when it goes unnoticed even by experts such as GP. At the same time, you want to claim authoritative control over HTML, yet show no sign of respecting other established standards and standard bodies such as ISO/IEC, IETF (eg avk's URL "standard"), and W3C?
- domenicd 7y ago
  I'm not sure what you mean by drop and then re-introduce, buried in a Git commit. We made a single commit to remove keygen, after displaying a public deprecation-will-be-removed notice in the spec for some years. Dropping keygen was part of a highly-public pull request, which gathered discussion from all browser vendors, as well as interested community members. The pull request was only merged once all four browser vendors supported removal (2 had already removed by that point).

tannhaeuser 7y ago

The narrative that "HTML5 looked at what browsers do, rather than following ivory tower SGML" is simply a myth and not backed up by facts. Ian Hickson introduced sectioning elements, the whole flawed outlining algorithm idea, and the aside element (presumably to make it easier to tell ads from content for Google's crawler), with lots of controversities at the time. The HTML spec is also chock full of inconsistencies of that time and mindset (for example, the allowed characters in ID attributes or general lexical rules for elements not matching CSS selectors' idea of an ID or element name) not actually supported by any browser. Please don't tell me SGML comments were the problem - SGML commenting syntax is straightforward, eg. anything in double-hyphens within a markup declaration is treated as a comment, and there can be multiple comments in a markup declaration (unlike XML). The only problem I see is that there is an interaction with an ancient form of JavaScript comment taking the form of double-hyphens, presumably to make JavaScript commenting uniform with HTML syntax. Now the rules for terminating the content of a script element are dangerously bogus in ancient HTML, but HTML5 has done nothing to fix the situation. In any case, WHATWG has driven almost all web browsers out of existence already; appealing to what "browser vendors" (Google) actually do is not the solution, but part of the problem, obviously.

om2 7y ago
The HTML parsing algorithm looked at what browsers do. WHATWG HTML also included other innovations, some of which didn’t entirely work out. Nowadays, new additions are not added so loosely and there is a better defined working mode and governance policy.
- tannhaeuser 7y ago
  "Government policy" yeah right. Chrome implements stuff, and Moz has to follow suit; then it gets prescribed in WHATWG's spec. OTOH, stuff introduced by Moz that Chrome doesn't implement gets removed from the spec. Such as much needed new elements for basic declarative UIs (menu, menuitem) to fight over-reliance on JavaScript and CSS hacks, introduced by FF but boycotted by Chrome. As was part of the WHATWG snapshot on which W3C HTML 5.1 was based, and removed in W3C HTML 5.2. There's no evidence Hixie analyzed "what browsers were doing". There is, however, evidence that Hixie just made up new elements as he saw fit [1]. [1]: https://www.webdesignerdepot.com/2013/the-harsh-truth-about-html5s-structural-semantics-part-1/ https://www.webdesignerdepot.com/2013/the-harsh-truth-about-...