5 ms·

The markup parts of HTML (e.g. the parsing) are pretty frozen and have been for a while. This is the part that can sort of argue it used to be based on SGML (t

The markup parts of HTML (e.g. the parsing) are pretty frozen and have been for a while. This is the part that can sort of argue it used to be based on SGML (though now it's not, for various reasons). The "HTML spec" includes a lot of APIs and processing model details that need tweaking as new constraints come up. A good example is that a lot of APIs that involve cross-window access need changes to their specifications in a process-per-origin world; the old spec text assumes everything can always be done synchronously, but that's not actually possible in that world as far as I can tell. This, and fixing security bugs in the spec that get found from time to time are far from "no good reasons"! None of the recent HTML spec changes would have affected "wellformedness" of an existing document in the markup sense. They're mostly about fixing spec bugs (in that the spec doesn't match what web sites expect!) in complicated areas like security, navigation, etc.

tannhaeuser 7y ago
> it used to be based on SGML (though now it's not, for various reasons) HTML doesn't cease to be based on SGML by mere declaration, or even by brittling it to the point it can't be parsed by any known formal standard. That's more a political stance, as in American isn't English or some such. WHATWG's formulation of HTML has deliberately distanced itself from SGML out of ignorance and a desire to not being accountable or formally verifiable (aka move fast and break things) against established, rich theoretical foundations of markup languages. And it shows: already in a paper I published two years ago [1], I show flaws in HTML as described by WHATWG, some of which have since been fixed ([3]). Not only is the concept of "transparent markup" flawed and underspecified, it also has since be used in the definition of the content model for the dl element, and as an unintended consequence also the div element (cf [2]), flaws that could be easily avoided by just using SGML for the grammar WHATWG is attempting to describe when SGML has been around for ages. It's also not entirely true that WHATWG HTML can parse all legacy docs. For example, the keygen element has been removed, and while not a terrible loss as such ;), since keygen is a void element (an element with declared content EMPTY in SGML parlance), its presence in a legacy document (eg without an end-element tag) will make HTML5 parsers fail hard ([4]). It's also completely unclear which version of HTML is being validated by eg. W3C's nu or another validator. Heck, even the spec text for WHATWG HTML itself reads > This file is NOT HTML, it's a proprietary language that is then post-processed into HTML when a large portion of the spec text portrays HTML in the role of an authoring language. So tell me why, as an author, I should follow WHATWG's vision for HTML? As you say yourself, WHATWG hasn't advanced HTML the markup language at all, and has rather prevented the evolution of declarative UI features, to the effect of making JavaScript essential for all but the most basic documents. [1]: http://archive.xmlprague.cz/2017/files/xmlprague-2017-proceedings.pdf http://archive.xmlprague.cz/2017/files/xmlprague-2017-procee... [2]: https://github.com/w3c/html/issues/1116 https://github.com/w3c/html/issues/1116 [3]: https://github.com/whatwg/html/commit/6e305c457e42276bf275b8432302a32c929b0eb8 https://github.com/whatwg/html/commit/6e305c457e42276bf275b8... [4]: Edit: this affects differences introduced in HTML 5.2 vs HTML 5.1, not some distant archaic HTML 4 version
- bzbarsky 7y ago
  > 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?

tannhaeuser 7y ago

> it used to be based on SGML (though now it's not, for various reasons) HTML doesn't cease to be based on SGML by mere declaration, or even by brittling it to the point it can't be parsed by any known formal standard. That's more a political stance, as in American isn't English or some such. WHATWG's formulation of HTML has deliberately distanced itself from SGML out of ignorance and a desire to not being accountable or formally verifiable (aka move fast and break things) against established, rich theoretical foundations of markup languages. And it shows: already in a paper I published two years ago [1], I show flaws in HTML as described by WHATWG, some of which have since been fixed ([3]). Not only is the concept of "transparent markup" flawed and underspecified, it also has since be used in the definition of the content model for the dl element, and as an unintended consequence also the div element (cf [2]), flaws that could be easily avoided by just using SGML for the grammar WHATWG is attempting to describe when SGML has been around for ages. It's also not entirely true that WHATWG HTML can parse all legacy docs. For example, the keygen element has been removed, and while not a terrible loss as such ;), since keygen is a void element (an element with declared content EMPTY in SGML parlance), its presence in a legacy document (eg without an end-element tag) will make HTML5 parsers fail hard ([4]). It's also completely unclear which version of HTML is being validated by eg. W3C's nu or another validator. Heck, even the spec text for WHATWG HTML itself reads > This file is NOT HTML, it's a proprietary language that is then post-processed into HTML when a large portion of the spec text portrays HTML in the role of an authoring language. So tell me why, as an author, I should follow WHATWG's vision for HTML? As you say yourself, WHATWG hasn't advanced HTML the markup language at all, and has rather prevented the evolution of declarative UI features, to the effect of making JavaScript essential for all but the most basic documents. [1]: http://archive.xmlprague.cz/2017/files/xmlprague-2017-proceedings.pdf http://archive.xmlprague.cz/2017/files/xmlprague-2017-procee... [2]: https://github.com/w3c/html/issues/1116 https://github.com/w3c/html/issues/1116 [3]: https://github.com/whatwg/html/commit/6e305c457e42276bf275b8432302a32c929b0eb8 https://github.com/whatwg/html/commit/6e305c457e42276bf275b8... [4]: Edit: this affects differences introduced in HTML 5.2 vs HTML 5.1, not some distant archaic HTML 4 version

bzbarsky 7y ago
> 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?