[Responder] Boris Zbarsky
Fundamentally, if UAs treat all HTML versions as the same there is no need for versioning information. So a proposal to create such information presupposes that UAs will NOT treat versions the same. We have this to a small extent now in terms of quirks mode, and even that is a significant maintenance burden. So in effect, a proposal that we introduce versioning is a proposal that favors big players over small ones in the HTML space: the next obvious course of action is to make sure several incompatible versions of HTML are created and that all need to be supported. This raises barriers to entry into the field, and while it may be good for certain W3C member companies I believe it's very bad for HTML and HTML consumers as a whole. I can see various scenarios where a producer might want to keep internal versioning information, but I believe this can be put in a comment as well as in a doctype, and in any case ideally should be removed before publishing the content (so that conformance issues don't arise even is such tools want to put the information in the doctype). While I agree that it's possible that in the future a situation will arise where HTML documents from that point on need to be differentiated from all preceding ones, such a situation has not arisen in practice in the nearly 20 years of HTML's existence. In the unlikely event that it does arise, that would be the right time to consider adding a version indicator. Clearly this would not be done lightly at that point, but neither should changes to HTML that are backwards-incompatible to the extent envisioned in this scenario be undertaken lightly.