3 ms·

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

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

by rhdunn 4y ago

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.