Re: Draft [URL] reference update to informative text

On Wed, Oct 8, 2014 at 11:04 AM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> From: Chris Wilson [mailto:cwilso@google.com]
> > That said - man, it sure would help me feel better about the stability
> and applicability if the WHATWG had any kind of addressing of the places
> where this spec (and others) fail those NRP principles - say, a stability
> section, or a clear "this is how this is likely to change in the future".
> Or a stable snapshot that doesn't have an derogatory lawyercat title, but
> does have a clear "you probably want the living standard over here"
> pointer.  Because right now, the answer in every case has been "everything
> can change at any time", which is a concerning failure.
>
> Well, the answer is certainly more nuanced than that. (We also discussed
> this during the TAG F2F, so I feel it important to relay here, to the
> extent the minutes may not cover it.) It's "anything could change *as long
> as it doesn't break the web*." That guarantee is actually a very strong
> one, and also probably the strongest you'd want to make---anything stronger
> would unnecessarily constrain evolution and bugfixes.
>

I believe the unstated intent is much stronger than this, yes, and of
course the entire issue is much more nuanced than this.  But there *is* no
stated guarantee.  This is the general chain of problems I have with no
stated due process and singular authoritative control.  I believe it's
quite possible to have strong stated processes around stability of
individual specs without needlessly constraining evolution (and certainly
not bugfixing/errata-level issues).

In short: "HTML" has always been a living standard*.  HTML2, HTML3.2,
HTML4, HTML 4.01 were not, and (sadly) did not do a good job of
forward-pointing.  That was broken, and needs to change.  That doesn't mean
the idea of stability inflection points in standards is a bad thing.

(* yes, there was a period of time between 1999 and 2004 where it may have
felt like HTML was dead.  But it wasn't.  And we can, and have, put in
place better processes to enable maintenance, and will continue to do more.)

Relatedly, I'd like to call your attention to the difference between Living
> Standards like URL, HTML, DOM, and XHR versus "soon to become living
> standards" like Streams [1] and Books [2], or "dreams of becoming a living
> standard" like Loader [3]. We take our commitment to true Living Standards
> very seriously. While the APIs in Streams might change a bit---in
> backward-incompatible ways---as they get implemented, the APIs of URL or
> DOM are not going to change backward-incompatibly. They're very stable in
> that regard. We're hoping to roll out better indications of this sort of
> stability across many WHATWG specs, e.g. based on caniuse data [5] or test
> results [6].
>

I think caniuse data is pretty high-level.  I'm more concerned about, say,
adding a new attribute to <video>: e.g. the editor decides to add a
"startAt" parameter to tell the video to begin at a particular time.  Does
this cause the entire section to not be green?  Is it a separate section?
What does that mean to the last version of IE that shipped that claimed to
fully support <video>?

There is one other sense of stability that is less consequential but still
> worth caring about, viz. stability of section IDs or vocabulary used, for
> when the referencing spec wants to deep-link ...
>

I agree that's a separate (important but likely fixable) issue.

-Chris