3 ms·

> B) The WHATWG "living standard" is not really a standard at all as many engineers understand or would like it. I've found it incredibly useful. For the first

> B) The WHATWG "living standard" is not really a standard at all as many engineers understand or would like it. I've found it incredibly useful. For the first time, someone actually wrote down all the details of how to do real-world HTML parsing, rather than having that knowledge all embedded in web browsers. WHATWG specifies how HTML actually works. You can follow the WHATWG standard and actually implement a web browser, or an HTML parser.

rhdunn 4y ago
The key issue is the "Living Standard" part, not the technical details of the specification. Practically, it means that an implementor needs to record the date at which they implemented a given piece of functionality. It means that: 1. different implementors (e.g. the various HTML parsers in Java, C#, etc.) can be on different revisions, so can have subtly different behaviour while being conformant to those versions of the spec; 2. an implementor that implements a given algorithm/behaviour in the spec can have the details of that change -- therefore, they need to follow all commits to the spec in order to figure out what has changed; 3. references to the spec (numbered headings -- e.g. "5. parsing", and URIs) can change when content gets moved, merged, renamed, making other specs that reference those easily outdated. Having numbered specifications makes it easier to tell what is in that version and what has changed between the versions. Imagine writing a Java, C#, etc. application to a Living Standard. It would quickly become unmanageable as libraries would be using different features from different revisions.
- JoshTriplett 4y ago
  I personally think the web should have used a more solid standard from day 1. If something like strictly validated XHTML had been the very first thing shipped on the web, and anything that didn't validate wouldn't display, we'd have had a very different web. But given the web we have, I think we need to document it. > It would quickly become unmanageable as libraries would be using different features from different revisions. As far as I know, HTML5 is generally forward-compatible. Once something has actually shipped in the standard, there's a question of "how new of a browser do you need to use this", but not "how old".
  - layer8 4y ago
    The issue is, suppose you implement an HTML viewer component in Java/C#/whatever, which could be used, for example, to display help pages in a desktop application. You’d like to tell the users of that component that it supports HTML version x.y, but with the “living standard” there is no x.y to point to. Content providers instead have to use trial and error to see what renders in that viewer and what doesn’t, instead of having a specific standard they can refer to. Similarly, you can’t have an HTML content generator that would guarantee that its output conforms to HTML x.y, and thus could be used to produce content for the viewer component. The only thing that the respective providers of the viewer component and of the content generator could do is to provide a copy of a snapshot of the “living standard” to express which revision they support. But since there are no named/numbered versions, that’s not very practical, and it makes it hard to determine compatibility between such software modules. This is what the “living standard” fails at, as a standard. As pointed out elsethread, it also fails by leaving a lot unspecified.
- IshKebab 4y ago
  If you've done any web work at all though it's pretty obvious that the edges of the spec are never especially well specified and browsers have different implementations all the time. Sometimes deliberately. So you don't really lose anything at all by having a continuously updated spec instead of a versioned spec. Hell if you want you can think of the date as the version. Then there's no difference at all. Many versioning systems work like that. > Imagine writing a Java, C# etc. application to a Living Standard. Those are bad examples because they have implementations that are overwhelmingly popular and therefore the de facto standard is "what does the official compiler do?". A better example is C++. Guess what? C++ implementations are incomplete and patchy and often have subtle differences just like with web browsers.
andrewmcwatters 4y ago
> WHATWG specifies how HTML actually works. You can follow the WHATWG standard and actually implement a web browser, or an HTML parser. No they didn't. In fact there are whole sections of the web standards that have no normative details on how to implement them other than descriptive notes about how the end results should function. It's a core reason why the Internet Explorer team had issues with CSS composition. It's UNDEFINED. Not sure what "standard" you're reading. No implementor wants to write against a "living standard" that you have to fork for a pinned date of what your rasterizer conforms to. WHATWG just links to a bunch of W3C actual versioned standards for the majority of specifications, most of which they didn't actually want to do work on. Maybe HTML parsing is one of them, but HTML parsing mechanics are perhaps the least interesting of all of the specifications. Oh by the way, for people who actually read the specifications required to build a full web browser know that you still actually have to read WebKit, Chromium, and Gecko/Quantum codebases to understand what they have all silently agreed to do that isn't documented in the specifications. Why? Because further still, there are whole sections of web standards that are intentionally undefined and left to vendors to implement however they want.
- JoshTriplett 4y ago
  > It's a core reason why the Internet Explorer team had issues with CSS composition I may be entirely mistaken, but isn't that just because WHATWG hasn't forked CSS away from W3C? Perhaps this is an indication that they should? > Maybe HTML parsing is one of them, but HTML parsing mechanics are perhaps the least interesting of all of the specifications. They're something that was previously (as far as I know) completely undocumented, for which there's now a publicly documented algorithm that actually parses real web content. I think that's a good approach to provide for more things, and there are still plenty of things for which we don't have enough information like that. > Because further still, there are whole sections of web standards that are intentionally undefined and left to vendors to implement however they want. Other than the utter garbage fire that is DRM, what other aspects are "intentionally undefined"? (Genuine question, would love to learn this, and would be unpleasantly surprised to find out that there are more.)
  - 4y ago

rhdunn 4y ago

The key issue is the "Living Standard" part, not the technical details of the specification. Practically, it means that an implementor needs to record the date at which they implemented a given piece of functionality. It means that: 1. different implementors (e.g. the various HTML parsers in Java, C#, etc.) can be on different revisions, so can have subtly different behaviour while being conformant to those versions of the spec; 2. an implementor that implements a given algorithm/behaviour in the spec can have the details of that change -- therefore, they need to follow all commits to the spec in order to figure out what has changed; 3. references to the spec (numbered headings -- e.g. "5. parsing", and URIs) can change when content gets moved, merged, renamed, making other specs that reference those easily outdated. Having numbered specifications makes it easier to tell what is in that version and what has changed between the versions. Imagine writing a Java, C#, etc. application to a Living Standard. It would quickly become unmanageable as libraries would be using different features from different revisions.

JoshTriplett 4y ago
I personally think the web should have used a more solid standard from day 1. If something like strictly validated XHTML had been the very first thing shipped on the web, and anything that didn't validate wouldn't display, we'd have had a very different web. But given the web we have, I think we need to document it. > It would quickly become unmanageable as libraries would be using different features from different revisions. As far as I know, HTML5 is generally forward-compatible. Once something has actually shipped in the standard, there's a question of "how new of a browser do you need to use this", but not "how old".
- layer8 4y ago
  The issue is, suppose you implement an HTML viewer component in Java/C#/whatever, which could be used, for example, to display help pages in a desktop application. You’d like to tell the users of that component that it supports HTML version x.y, but with the “living standard” there is no x.y to point to. Content providers instead have to use trial and error to see what renders in that viewer and what doesn’t, instead of having a specific standard they can refer to. Similarly, you can’t have an HTML content generator that would guarantee that its output conforms to HTML x.y, and thus could be used to produce content for the viewer component. The only thing that the respective providers of the viewer component and of the content generator could do is to provide a copy of a snapshot of the “living standard” to express which revision they support. But since there are no named/numbered versions, that’s not very practical, and it makes it hard to determine compatibility between such software modules. This is what the “living standard” fails at, as a standard. As pointed out elsethread, it also fails by leaving a lot unspecified.
IshKebab 4y ago
If you've done any web work at all though it's pretty obvious that the edges of the spec are never especially well specified and browsers have different implementations all the time. Sometimes deliberately. So you don't really lose anything at all by having a continuously updated spec instead of a versioned spec. Hell if you want you can think of the date as the version. Then there's no difference at all. Many versioning systems work like that. > Imagine writing a Java, C# etc. application to a Living Standard. Those are bad examples because they have implementations that are overwhelmingly popular and therefore the de facto standard is "what does the official compiler do?". A better example is C++. Guess what? C++ implementations are incomplete and patchy and often have subtle differences just like with web browsers.

andrewmcwatters 4y ago

> WHATWG specifies how HTML actually works. You can follow the WHATWG standard and actually implement a web browser, or an HTML parser. No they didn't. In fact there are whole sections of the web standards that have no normative details on how to implement them other than descriptive notes about how the end results should function. It's a core reason why the Internet Explorer team had issues with CSS composition. It's UNDEFINED. Not sure what "standard" you're reading. No implementor wants to write against a "living standard" that you have to fork for a pinned date of what your rasterizer conforms to. WHATWG just links to a bunch of W3C actual versioned standards for the majority of specifications, most of which they didn't actually want to do work on. Maybe HTML parsing is one of them, but HTML parsing mechanics are perhaps the least interesting of all of the specifications. Oh by the way, for people who actually read the specifications required to build a full web browser know that you still actually have to read WebKit, Chromium, and Gecko/Quantum codebases to understand what they have all silently agreed to do that isn't documented in the specifications. Why? Because further still, there are whole sections of web standards that are intentionally undefined and left to vendors to implement however they want.

JoshTriplett 4y ago
> It's a core reason why the Internet Explorer team had issues with CSS composition I may be entirely mistaken, but isn't that just because WHATWG hasn't forked CSS away from W3C? Perhaps this is an indication that they should? > Maybe HTML parsing is one of them, but HTML parsing mechanics are perhaps the least interesting of all of the specifications. They're something that was previously (as far as I know) completely undocumented, for which there's now a publicly documented algorithm that actually parses real web content. I think that's a good approach to provide for more things, and there are still plenty of things for which we don't have enough information like that. > Because further still, there are whole sections of web standards that are intentionally undefined and left to vendors to implement however they want. Other than the utter garbage fire that is DRM, what other aspects are "intentionally undefined"? (Genuine question, would love to learn this, and would be unpleasantly surprised to find out that there are more.)
- 4y ago