4 ms·

Just skimming through the intro chapter I already spotted inaccuracies regarding SGML. For example: > The following are equivalent: <link rel="stylesheet" href

Just skimming through the intro chapter I already spotted inaccuracies regarding SGML. For example: > The following are equivalent: <link rel="stylesheet" href="style.css" /> [and] <link rel="stylesheet" href="style.css">> No they're not. The author should study the 1998 WebSGML adaptations to ISO 8879 (the SGML spec), and in particular the NETENABL IMMEDNET feature. I mean, I welcome discussion about HTML parsing; just not the kind of narrative painting HTML5 as some kind of academic or community consensus when it's very clear that HTML5 as it is is a dead end, and a regression due to its monolithic nature tying a parsing spec to a concrete markup language, unlike SGML and XML.

edoceo 5y ago
Loads of changes have happened since 1998. And both of those elements render and do the exact same thing - or what am I (a non-SGML expert) missing? Edit: I read this but it didn't add much clarity -- https://medium.com/hackernoon/to-close-or-not-to-close-4365d24853ff https://medium.com/hackernoon/to-close-or-not-to-close-4365d...
- innocenat 5y ago
  The GP quote was in SGML History section, not HTML section. So yes, he was talking about 1998.
- tannhaeuser 5y ago
  The context I cited is about parsing the XMLish "/>" empty-element tag which is not treated in the way the author thinks. WebSGML (aka ISO 8879 Corr 2/Annex K) has the option to parse this XML-like rather than under traditional SGML rules; which is no surprise since W3C XML and ISO (Web)SGML were published in a coordinated way and authored by the same people. Loads of changes may have happened to CSS and JS, but HTML has remained largely the same, save for the addition of a couple elements (section, article, main, header/footer added by Ian Hickson early on without any input by other parties) and import of SVG (the major contribution of XML) directly into HTML. Which is exactly the problem: HTML hasn't advanced for eg mobile, but everything else around it has turned into absurd complexity so we can continue to pretend we're writing 1990's casual academic content (the original use case for HTML the markup language). When, of all the languages in the web stack, markup is the one thing that has typing, schemas, and a schema evolution story.
sanxiyn 5y ago
I agree HTML5 is very unsatisfactory in tying parsing to markup, but it has an extremely important and redeeming virtue of parsing existing HTML documents in the wild. I agree no one should base a new markup on HTML5, but eh, no one is? You seem to be attacking a strawman there.
masswerk 5y ago
> The author should study the 1998 WebSGML adaptations to ISO 8879 (the SGML spec) Mind that the author is literally one of the designers and maintainers of the HTML5 parsing specs. From the section "About the author": > He contributed to the design of some aspects of the HTML parser specification […] and is currently an editor of the WHATWG HTML standard and the WHATWG Quirks Mode standard.
- tannhaeuser 5y ago
  So what? Does that mean we can't point out false claims the author is making in support of his HTML5 narrative? WHATWG (and W3C) isn't exactly a shining example of succesfull standardization when measured in terms of broad community involvement given their pay-as-you-go statue, or measured by adoption considering there are only about two browser code bases left. It has been "whatever Chrome does" for years now, not to speak of being a monolithic spec the size of the NYC phone book and a process having never achieved any final published version after 17 years of work.
  - sanxiyn 5y ago
    Isn't it three? We have Blink, WebKit, and Gecko. Edit: Also, while WHATWG may not be a resounding success, WHATWG's HTML5 parsing definitely is. We now have large number of interoperable implementations that can parse existing HTML documents in the wild. It is one of the most dramatic success of standardization I have witnessed.
    - tannhaeuser 5y ago
      Blink is a fork of WebKit, so can't be counted as independent implementation.
      - squiggleblaz 5y ago
        (a) You claimed two codebases before. Switching to "independent implementation" is shifting the goalposts. (b) The reason you fork a codebase is to make it different. They've been forked for eight years or so now. This is longer than many codebases even exist for! I don't know how different they are in practice (especially in the matter of parsing), but I think it's unreasonable to assert that just because they're forked, ipso facto they are not independent. Instead, you should have to show that they are not independent and then explain this in terms of common origin. edit: To add to this point (b), afaik the old Netscape and IE had a common origin, in that they both derived from NCSA Mosaic. But it would be ludicrous to imply that they were in any sense equivalent!

edoceo 5y ago

Loads of changes have happened since 1998. And both of those elements render and do the exact same thing - or what am I (a non-SGML expert) missing? Edit: I read this but it didn't add much clarity -- https://medium.com/hackernoon/to-close-or-not-to-close-4365d24853ff https://medium.com/hackernoon/to-close-or-not-to-close-4365d...

innocenat 5y ago
The GP quote was in SGML History section, not HTML section. So yes, he was talking about 1998.
tannhaeuser 5y ago
The context I cited is about parsing the XMLish "/>" empty-element tag which is not treated in the way the author thinks. WebSGML (aka ISO 8879 Corr 2/Annex K) has the option to parse this XML-like rather than under traditional SGML rules; which is no surprise since W3C XML and ISO (Web)SGML were published in a coordinated way and authored by the same people. Loads of changes may have happened to CSS and JS, but HTML has remained largely the same, save for the addition of a couple elements (section, article, main, header/footer added by Ian Hickson early on without any input by other parties) and import of SVG (the major contribution of XML) directly into HTML. Which is exactly the problem: HTML hasn't advanced for eg mobile, but everything else around it has turned into absurd complexity so we can continue to pretend we're writing 1990's casual academic content (the original use case for HTML the markup language). When, of all the languages in the web stack, markup is the one thing that has typing, schemas, and a schema evolution story.

sanxiyn 5y ago

I agree HTML5 is very unsatisfactory in tying parsing to markup, but it has an extremely important and redeeming virtue of parsing existing HTML documents in the wild. I agree no one should base a new markup on HTML5, but eh, no one is? You seem to be attacking a strawman there.

masswerk 5y ago

> The author should study the 1998 WebSGML adaptations to ISO 8879 (the SGML spec) Mind that the author is literally one of the designers and maintainers of the HTML5 parsing specs. From the section "About the author": > He contributed to the design of some aspects of the HTML parser specification […] and is currently an editor of the WHATWG HTML standard and the WHATWG Quirks Mode standard.

tannhaeuser 5y ago
So what? Does that mean we can't point out false claims the author is making in support of his HTML5 narrative? WHATWG (and W3C) isn't exactly a shining example of succesfull standardization when measured in terms of broad community involvement given their pay-as-you-go statue, or measured by adoption considering there are only about two browser code bases left. It has been "whatever Chrome does" for years now, not to speak of being a monolithic spec the size of the NYC phone book and a process having never achieved any final published version after 17 years of work.
- sanxiyn 5y ago
  Isn't it three? We have Blink, WebKit, and Gecko. Edit: Also, while WHATWG may not be a resounding success, WHATWG's HTML5 parsing definitely is. We now have large number of interoperable implementations that can parse existing HTML documents in the wild. It is one of the most dramatic success of standardization I have witnessed.
  - tannhaeuser 5y ago
    Blink is a fork of WebKit, so can't be counted as independent implementation.
    - squiggleblaz 5y ago
      (a) You claimed two codebases before. Switching to "independent implementation" is shifting the goalposts. (b) The reason you fork a codebase is to make it different. They've been forked for eight years or so now. This is longer than many codebases even exist for! I don't know how different they are in practice (especially in the matter of parsing), but I think it's unreasonable to assert that just because they're forked, ipso facto they are not independent. Instead, you should have to show that they are not independent and then explain this in terms of common origin. edit: To add to this point (b), afaik the old Netscape and IE had a common origin, in that they both derived from NCSA Mosaic. But it would be ludicrous to imply that they were in any sense equivalent!