Change Proposal for ISSUE-140

Summary

Conformance to HTML should not have version indicators.

Rationale

As previously resolved, the HTML language defined by the HTML5 spec does not have a version indicator. Distinguishing between incompatible versions of HTML was deemed to be “something that will likely never exist”, noting that “something that has no observable effect leads to confusion; and the indicator itself would tend to encourage fragmentation and additional modes — something that there is general consensus is undesirable”.

Equivalent arguments apply to the name used to refer to documents that conform to the language. HTML5 redefines HTML, such that when it is published it obsoletes previous definitions: it will define an HTML document, and indeed will be the only current definition of an HTML document. Should a future standard, maybe HTML5.1 or HTML6, change the definition of HTML further then HTML5's definition of an HTML document will no longer be relevant.

Changes to HTML are designed to help authors. It is in an author's interests for a document to be considered relative to the latest standard, rather than an earlier one which is known to be buggy, incomplete, or misguided (at least one of which must be the case in order for a successor standard to have been issued).

In particular, a document could be currently not conforming solely because of a bug in the standard. If a later standard is issued which fixes the bug then the author's document should be considered conforming. Considering it to be a non-conforming HTML5 document rather than, say, a conforming HTML6 document is a distinction with no benefit: that it happened to be non-conforming when it was written is not relevant. The bug in the HTML definition has been fixed, so it makes sense to refer to it as a conforming HTML document.

The same applies to an author currently using features defined in HTML4 plus <canvas> in a web page. When HTML5 is published and adds <canvas> to the language, continuing to refer to the web page as an invalid HTML4 document doesn't achieve anything; it will be a valid HTML document.

Changes in conformance can occur for many reasons, including:

• A new feature being added.
• Something which authors were doing anyway being recognized as safe, so now sanctioned.
• Spec bugs being corrected, changing what is allowed to reflect what the intention always ways.
• Something which has been found to cause problems not being allowed.

In a situation where an author was doing X unaware that this causes problems and X happens to conform and then a new edition of the HTML standard is issued which prohibits X, it is irritating for the author that her document has suddenly become non-conforming. But there are plenty of examples where the opposite will occur — a document will become conforming, thereby benefiting authors.

Even in the ‘irritating’ case, it is to the author's benefit to learn what the problems with X are; pretending that the problems don't exist because they hadn't been identified (or, more likely, they had been identified but a spec correcting them hadn't yet made it through to being published) at the time her document was written doesn't actually make the problems go away. It does the author a disservice to pretend that they have.

The suggestion in the Change Proposal that applicable specifications could define their own terms will lead to a myriad of definitions related to HTML conformance and will not make the situation any clearer than simply using what is there today.

Additional points yet to be properly documented herein:

• Naming it "conforming HTML5 document" vs "conforming document" is a non-issue, since naturally the spec defines documents that conform to itself — adding "HTML5" to the term is merely a tautology. All that adding an explicit name to this is going to do is make editing the spec more of a pain for the editor, since the WHATWG has moved away from "HTML5" but is using the same source document.

• Explicitly differentiating conformance to the spec alone (presumably actually the spec plus all its dependencies) from conformance to the spec and other established relevant specs disenfranchises the other specs. For example, it means that people who use RDFa have to convince their target market that it's ok to use "HTML5+RDFa" rather than just saying that RDFa is conforming in HTML5.

Details

No change.

Impact

By not introducing versions in HTML conformance we keep it clear HTML does not use versions and we prevent the need to introduce lots of definitions around HTML conformance.