Change Proposal for ISSUE-140

Summary

Conformance to HTML should not have version indicators.

Rationale

The Change Proposal suggests several distinct changes. This zero-edit counter-proposal discusses each of them in turn:

Putting a Version Indicator in ‘Conforming Documents’

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 a conforming document written in HTML, 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 a 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 who is currently using, say, some basic features defined in HTML4 (and which are still in HTML5) 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 non-conforming HTML4 document doesn't achieve anything; it will be a conforming document to the HTML spec.

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.

Putting a version indicator in the name would also avoid 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.

Putting ‘HTML’ in ‘Conforming Documents’

The current draft spec defines “conforming documents” without any mention of HTML. The above explains why putting “5” in there is undesirable; for completeness the following covers why the term doesn't need changing to “conforming HTML documents”.

Doing so would be a tautology: by definition, the spec's definition of conforming documents is documents that conform to itself. Since the subject matter of the spec is HTML, it's clear that that is the kind of conformance it is describing. Documents which conform to some other spec are conforming documents of whatever that other spec defines.

A term defined in a spec only has meaning where the spec's jurisdiction is recognized. That a conforming ODF document does not conform to the HTML spec and would not be labelled a conforming document by it is irrelevant, because nobody would be applying the HTML spec to an ODF document in the first place.

Putting ‘HTML’ in the label used to describe documents conforming to the spec adds nothing, so requiring the change creates work for the editor for no benefit.

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.

Definition of ‘Applicable Specification’

A specification is applicable in circumstances where those in charge of the situation recognize it as applying. That is not a particular preference, merely a description of what happens. Nothing written in any specification can alter that: if people ignore a specification (such as XHTML2) then the specification does not apply to them; similarly, if people adopt a specification as being valid to them (such as using autocomplete=off in what is otherwise an HTML document conforming to HTML4, and considering that to be a conforming document for their purposes) then any specification is powerless to stop that.

As such, it is fiction for the HTML5 spec to pretend that anything else is the case. It is most helpful for readers of the spec to have this honest description of the state of affairs, and for elsewhere in the spec to be able to refer to it. The note with the ‘random junk’ example clarifies this, and should be retained so that readers are not misled into believing otherwise.

Restrictions on Applicable Specifications

An applicable specification is by definition overriding part of the HTML standard; where the two conflict, the applicable specification ‘wins’. So any restrictions the HTML spec puts on applicable specifications are pointless: an applicable specification could choose to override the section making those restrictions, removing them.

The HTML spec has jurisdiction only because people choose to apply it to their documents. If people choose to apply some other specification instead, or in combination, the HTML spec can't stop them. If an entirely separate group completely redefines what “HTML” means and publishes that as a rival spec, what matters is not what either spec says is permissible to do with the term “HTML”, but which spec users of HTML choose to follow.

If a particular extension, say RDFa, takes off such that among a particular community (or possibly even web developers as a whole) they use the term ‘conforming documents’ to refer to those which meet the requirements of the HTML spec as extended by a particular RDFa spec, then that's what the term shall mean.

Indeed, explicitly differentiating conformance to the spec alone (or to the spec plus all its dependencies) from conformance to the spec and other established relevant specs disenfranchises the other specs, by making them second-class citizens for the purposes of advocacy. 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. Essentially, it introduces an additional artificial barrier to getting such extensions adopted.

The ‘applicable specifications’ definition is an intentional HTML extension mechanism, and the HTML spec should not disenfranchise those who wish to use it by excluding them from being able to say their documents conform to the HTML standard.

Details

No change.

Impact

Positive Impact

By not introducing versions in HTML conformance we keep it clear that conforming to the latest HTML definition is what is important, and we prevent the need to introduce lots of definitions around HTML conformance.

Negative Impact

None.