2 ms·

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 o

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.

2 ms·

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 o

by JoshTriplett 4y ago

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.