[Responder] Aryeh Gregor
First, point #11 of the Rationale suggests that if an incompatible change to HTML is ever needed, adding support for version indicators now will help to avert the cost of switching to the new and incompatible version. But according to the proposal, browsers will treat a versioned doctype the same as an unversioned one, so why not just use the latter exclusively? If versioning ever needs to be added in the future, add it then. Pages with plain can then be treated as "old" pages, while ones with the new versioning syntax (whatever it is) will be "new" ones. Indeed, this is exactly what HTTP did. HTTP 0.9 had no explicit versioning, and when HTTP 1.0 added versioning, it provided that "If the protocol version is not specified, the recipient must assume that the message is in the simple HTTP/0.9 format." This scheme proved successful in practice, obviously. It is not explained why permitting versioning now makes later incompatible changes easier. As far as I can tell, this eliminates the rationale for the entire proposal, because it leaves no reason to actually permit explicit versioning now. Second, the Change Proposal (also in point #11 of the Rationale) states: """ In the history of computer languages, there are no languages that have not evolved, been extended, or otherwise "versioned" as long as the language has been in use. This applies to network protocols, character encoding standards, programming languages, and certainly to every known technology found on the web. There are no known cases where a language hasn't gone through some at least minor incompatible change. The standards process is established as a way of evolving specifications and implementations in a way to reduce the likelihood of complete failure to interoperate, but certainly not to guarantee that no incompatible changes will be needed in the future. """ I believe this is materially very wrong. HTML, CSS, and JavaScript are all languages that have maintained an extremely high degree of backward compatibility, and in particular have not ever used explicit versioning to date (that is, none that authors or UAs respected in practice, formal talismans notwithstanding). There are many other languages and interfaces that try to maintain this level of compatibility as well. The Linux system call API, the X Window System, and the Windows system call interface have all kept changes down to a level where they do not require programs or operating systems to advertise particular versions. I cannot think of a single programming language that requires programs to explicitly state what version of the language they're written in. (Perhaps this just shows my limited knowledge of programming languages, but then the original Change Proposal should have given supporting evidence for the claim in the first place.) Indeed, it's difficult to think of successful technologies that really rely on explicit versioning in practice. HTTP and XML have explicit versions, but in practice they're stuck at 1.1 and 1.0 respectively, and any new features that are adopted in practice are added backwards-compatibly, without incrementing the version number. So although they technically have version numbers, they're not good support for this Change Proposal. It's true that all languages sometimes need to break backward compatibility a bit, but version indicators are rarely necessary or helpful in doing this. In most cases, such breakage is kept as minimal as possible, so incrementing a version number would be excessive. In some cases, such as Python, there are large-scale backward compatibility breaks, but version indicators are still not used -- because they impose a permanent cost on the language to moderately ease a temporary transition period. On top of that, even if a few other languages do use explicit version indicators in the real world, they are not in the same position as web technologies. HTML is used by billions of people every day, and there are trillions of web pages in existence, under the control of countless different authors. Browser implementers have consistently emphasized that in order for people to use their browsers, they *cannot* break significant numbers of web pages. It is not a question of whether we want to change HTML incompatibly; it is impossible whether we want to or not, because market forces prohibit it. No reason is given for why this situation would ever change, as long as HTML remains widely deployed. Thus adding explicit version indicators is not only useless in the event of an incompatible change, as I explain in my first point. It also exemplifies one of the cardinal problems with pursuing long-term theoretical purity over short- to mid-term pragmatism: it burdens the language with extra syntax to avoid a problem that will very likely never exist, so that the cure is worse than the disease. In summary, the proposal seeks to address a nonexistent problem, and fails to do even that. On a final and more minor note, I also specifically object to the suggestion that the wording "mostly useless" be changed. It's good to use clear and forceful wording to help get the message out to authors that doctypes have no real purpose on the web, since they don't control browser processing (except by avoiding quirks mode). Weaker wording like "of limited utility" would reduce the effectiveness of this message. We do not need to write the spec in an overly formal fashion if that reduces the effectiveness of its phrasing.