ISSUE-140 CCP — no conformance versions — rev 1

Hereby a more up to date version of the Counter Change Proposal for  
ISSUE-140. Thanks to all who contributed and gave feedback.

As document: http://wiki.whatwg.org/wiki/Change_Proposal_for_ISSUE-140

Converted to text:

==Summary==

Conformance to HTML should not have version indicators.

==Rationale==

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

=== Putting a Version Indicator in ‘Conforming Documents’ ===

As previously resolved[3], 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[1] 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.

[1]<http://lists.w3.org/Archives/Public/public-html/2011Jan/0239.html>
[2]<http://lists.w3.org/Archives/Public/public-html/2011Jan/att-0239/infrastructure_with_ISSUE-140_Proposal.html>
[3]<http://lists.w3.org/Archives/Public/public-html/2010Dec/0135.html>


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Thursday, 3 March 2011 13:13:47 UTC