search

w3c / WebPlatformWG

Web Platform Working Group pages
https://www.w3.org/WebPlatform/WG/
66 stars 92 forks source link

CFC: Make previous versions of HTML and XHTML obsoleteCFC: Make previous versions of HTML and XHTML obsolete #86

Closed LJWatson closed 7 years ago

LJWatson commented 7 years ago

This is a Call For Consensus (CFC) on the proposal to mark previous versions of HTML and XHTML obsolete.

The definition of an obsolete specification is found in section 6.1.2 of the W3C Process

"An Obsolete Recommendation is a specification that W3C does not believe has sufficient market relevance to continue recommending that the community implement it, but does not consider that there are fundamental problems that require the Recommendation be Rescinded. It is possible for an Obsolete Recommendation to receive sufficient market uptake that W3C decides to restore it to Recommendation status. An Obsolete Recommendation has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR licenses granted under the Patent Policy.">

The reason for this proposal is that these specifications are no longer recommended for implementation or use on the web platform. As older versions are superceded by new versions (as HTML5.0 has been superceeded by HTML5.1), the W3C should communicate this as clearly as possible to the web community.

The rationale for including both HTML and XHTML specifications in this CFC is that the WebPlat WG maintains specifications that include XHTML as well as HTML.

The specifications covered by this proposal are:

Please respond to this CFC by end of day on Tuesday 18th July 2017. If you choose not to respond to this CFC it will be taken as implicit support for the proposal. Your opinion is important though, so please take time to actively respond.

ZoeBijl commented 7 years ago

Would this mean they get a big / loud alert on them that tells visitors these specs are out-of-date? In which case I would +2 this because I often hear people getting confused by the vast amount of different versions of specs that are out there. I think we’ve all heard stories about somebody referencing the HTML 4 spec somewhere in the last 7 years.

akuckartz commented 7 years ago

:+1:

kborchers commented 7 years ago

Definitely a :+1: from me!

Boldewyn commented 7 years ago

Going with my gut, I'd :+1: the proposal. But with

  1. legacy software that still creates HTML: XSLT processors, EPUB generators, XML pipelines, ..., and
  2. legacy documents: substantial part of the web, most e-books, ...

being with us for years to come, it should be remembered, that the tagging as obsolete also includes a recommendation for consuming apps not to support those standards.

Of course, a HTML parser author should judge for herself, if it's useful to handle HTML 3 or XHTML 1.1 in their application. On the other hand, the standards becoming obsolete might serve as fig leaf for decisions in management to drop support for standards, that might affect many people.

Tl;dr: if the obsolete standards get a note attached, that the deprecation is meant more for the producing side than the consuming one (good ol' Postel's Law applied), I'm all in for this.

therealglazou commented 7 years ago

EPUB specs are still all active and directly refer to some of these old html/xhtml specs. I am therefore thinking they cannot be made obsolete, but only deprecated.

chaals commented 7 years ago

@therealglazou There is no designation "deprecated" for specifications published by W3C.

"Obsolete" specs are still available, and still Recommendations. The point is that no new references should be made to them, and new implementation work should be looking at newer specs. Does that match what you mean by "deprecated"?

@Boldewyn Yes, "Postel's law" still applies. In any event, the HTML 5.1 and HTML 5.2 specifications still cover consuming content that was written with obsolete features.

therealglazou commented 7 years ago

@chaals: and I am saying there is no guarantee EPUB 4 will reference the last update of html, in particular for compatiblity reasons. We can recommend that new specs should not reference older html specs, we cannot enforce it.

chaals commented 7 years ago

@therealglazou wrote:

We can recommend that new specs should not reference older html specs, we cannot enforce it.

Absolutely. The "Obsolete" status recognises this and doesn't try to enforce the Recommendation to reference something newer - indeed, it is explicitly possible to "unObsolete" a Rec if it sees a renaissance in relevance.

LaurenceRLewis commented 7 years ago

Thanks to everyone for clarifying the position. I support #86 Make previous versions of HTML and XHTML obsolete.

danbri commented 7 years ago

Given these clarifications, +1

therealglazou commented 7 years ago

I'm still unsure about the most recent specs in the list above, including the ones used by EPUB specs. Seems to me a bad idea.

LJWatson commented 7 years ago

@TheRealGlazou, We're discovering that the Process description of an obsolete spec needs improving!

Essentially W3C has a number of versions of HTML, all at Recommendation status. By making all but the most recent obsolete, we're saying that given a choice, the most recent Recommendation is the one we recommend people use.

So there is nothing to prevent someone from using an older version in a tool or publishing platform, but if someone creates a new tool or updates an existing tool, then W3C recommends they use the most recent version of the spec to do so.

Similarly, a developer can continue to use HTML5.0 or xHTML1.1 if they wish, but given a choice W3C recommends using HTML5.1. In other words, HTML5.1 becomes the recommended Recommendation.

travisleithead commented 7 years ago

+1. It will be good to have more explicit direction in the specs listed above for which spec is the new authoritative (leading-edge) source, rather than continuing to pile up old "recommendations".

danbri commented 7 years ago

I'm also wobbly about calling more recent (if ageing) specs "obsolete" if the latest recommendation is still being fully implemented across all relevant environments/contexts.

adrianba commented 7 years ago

In practice, the main effect of marking a Recommendation obsolete is to provide a forward link to the latest version. All Recommendations are "stable" in the sense that they don't change unless significant errata are found, especially when there are subsequent versions that accept changes.

In my mind, this is similar to IETF RFCs, which indicate in their header which documents a new document obsoletes, and which documents supersede it. In HTML, it is true that HTML 5.1 is intended to supersede HTML 5.0 and we should make specs in that way. It doesn't make apps that target HTML 5.0 invalid, it doesn't change the IPR considerations for HTML 5.0, it just means the document will have a forward link that says, essentially, "This document was superseded by this later one".

In that sense, it seems strange to me that we should argue that HTML 4 was superseded but HTML 5.0 has not been.

therealglazou commented 7 years ago

@LJWatson Leonie, definitions are one thing, words are another. "Obsolete" intrinsincly carries some meaning, without any extra Process-based definition. A dictionary entry for that word is "No longer in use; gone into disuse; disused or neglected". I am saying this is NOK for some of the specs listed above.

LJWatson commented 7 years ago

This CFC received numerous positive responses, and two partial objections.

The objections were to making HTML 5.0 obsolete, on the basis that it is still referenced by other specifications, used by existing tools, and as a reference point for authors.

When a new version of a specification reaches Recommendation, it becomes the authoritative version. HTML 5.1 replaced HTML 5.0, which replaced HTML 4.01 before that, and so on back down the line. Marking previous versions of a specification obsolete is just a formal recognition of this.

Marking a version obsolete does not prevent it from being used. An obsolete specification has the same status as a Recommendation, it is still covered by the W3C Patent Policy, and it doesn't change unless substantive errata are discovered (especially if those errata have already been addressed in a subsequent version of the specification).

The purpose of marking a specification obsolete, is to make it clear that it is no longer the authoritative version, and to point forward to the version that is. So, if a tool, publishing platform, or other specification uses a previous version of a specification like HTML 5.0, it can continue to do so without any problem. But by making HTML 5.0 and all its predecessors obsolete, we make it easy for someone learning HTML for the first time, someone who is creating a new tool or updating an existing one, or someone editing a current specification, to identify the latest authoritative version.

The chairs therefore do not feel the objections are relevant to obsolete specifications. Had the proposal been to rescind these specifications instead, then the concerns would have been well founded. The definition of a rescinded specification can be found in section 6.1.2 of the W3C Process:

"A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses, and believes is unlikely to ever be restored to Recommendation Status.">

Thus, the CFC passes, and the chairs will now ask the Director to initiate an AC review of this proposal (as required by the W3C Process).

The chairs are also aware that this is the first time a WG has followed this part of the W3C Process, so all the comments we received were helpful, thank you.