Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
LJWatson opened this Issue Jul 11, 2017 · 17 comments

Comments

Projects
None yet
@LJWatson
Copy link
Collaborator

LJWatson commented Jul 11, 2017

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

This comment has been minimized.

Copy link
Contributor

ZoeBijl commented Jul 11, 2017

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

This comment has been minimized.

Copy link

akuckartz commented Jul 11, 2017

👍

@kborchers

This comment has been minimized.

Copy link
Contributor

kborchers commented Jul 12, 2017

Definitely a 👍 from me!

@Boldewyn

This comment has been minimized.

Copy link

Boldewyn commented Jul 12, 2017

Going with my gut, I'd 👍 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

This comment has been minimized.

Copy link

therealglazou commented Jul 12, 2017

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

This comment has been minimized.

Copy link
Collaborator

chaals commented Jul 12, 2017

@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

This comment has been minimized.

Copy link

therealglazou commented Jul 12, 2017

@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

This comment has been minimized.

Copy link
Collaborator

chaals commented Jul 12, 2017

@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.

@Decrepidos

This comment has been minimized.

Copy link

Decrepidos commented Jul 12, 2017

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

@danbri

This comment has been minimized.

Copy link

danbri commented Jul 18, 2017

Given these clarifications, +1

@therealglazou

This comment has been minimized.

Copy link

therealglazou commented Jul 18, 2017

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

This comment has been minimized.

Copy link
Collaborator Author

LJWatson commented Jul 18, 2017

@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

This comment has been minimized.

Copy link
Member

travisleithead commented Jul 18, 2017

+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

This comment has been minimized.

Copy link

danbri commented Jul 18, 2017

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

This comment has been minimized.

Copy link
Contributor

adrianba commented Jul 19, 2017

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

This comment has been minimized.

Copy link

therealglazou commented Jul 19, 2017

@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

This comment has been minimized.

Copy link
Collaborator Author

LJWatson commented Jul 19, 2017

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.

@LJWatson LJWatson closed this Jul 19, 2017

@w3c w3c locked and limited conversation to collaborators Jul 19, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.