[Bug 25618] Extensibility: Offer spec-blessed ways to extend the algorithms and curves, rather than monkey-patching the spec

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618

--- Comment #38 from Boris Zbarsky <bzbarsky@mit.edu> ---
> By this logic, I might add, we can't ship Version 5 until we are done with
> Version 6. 

By this logic, when you start work on version 6 you need to add a link in
version 5 pointing out that it's no longer the most recent specification and
that version 6 exists.  Assuming you were talking about versions of
specifications.

If you were talking about versions of implementations, I have no idea what you
were trying to say.

> No one is "pretending" S2 doesn't exist.

Please put yourselves in the shoes of an implementor who is told to "implement
S1".  They find the S1 spec and implement.  How do they find out about S2?

> It seems like extension specs are needed in this case. 

I'm not extension specs at all.  I'm not even against extension specs that are
clearly labeled as "optional unless you want your UA to be usable in Russia";
in fact I'm quite for it.

I _am_ against non-discoverable extension specs.

Obviously I can't speak for Anne and Ryan here, but I suspect that they agree
with me.

> The argument is "People might think extension spec is implemented, realize it
> isn't, and file a bug report."

No, the argument is "A browser implementor will think this S1 is implemented
and ship it and sites will break in the browser because they assume that if S1
is implemented so is S2, otherwise they polyfill S1".

As in, if S2 is in fact a required consequence of having S1, then by not making
that clear you set up people implementing S1 to fail.

> If developers want to know what browsers definitely support an extension S2

Based on historical evidence, developers will just test their favorite browser
or maybe two and then if they support S2 will assume everyone who implements S1
does.  They are likely to not even realize that the things they're using are in
S2 and not in S1, since developer-facing blogs, documentation, etc, is not
likely to make that clear.

> Thus, the pain of not having the ability to easily extend 

Adding a single forward-reference line to a spec does not seem like a high bar
for "easily".

On the other hand, I think you underestimate the pain of "ship a browser that
causes pages to break because a spec was incomplete"; a pain we have ended up
dealing with on a fairly regular basis with W3C specs and are somewhat familiar
with.

Basically, you are prioritizing the comfort of the working group over
implementors.  This is a direct reversal of
<http://www.w3.org/TR/html-design-principles/#priority-of-constituencies>. 
You're not bound by that design principle of course, being a different working
group and all that, but I'll posit that design principle is still a good idea
in general.  You might disagree, of course, in which case we really do have a
fundamental disagreement.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 9 October 2014 15:40:38 UTC