On 12/16/13 4:51 PM, Oliver Hunt wrote:
> In my opinion the cost of maintaining an old version of the API may be annoying

It's more than that, if sites are really depending on it.

If sites are depending on it, then it needs to actually be specified, so 
that those sites work in more than one browser engine (and conversely, 
so that new browser engines know they need to implement this old version 
of the API).

What this means in practice one of the following happens:

1) Some UA ships a prefixed version, then sites start relying on it, 
then that UA can't remove it and we need to standardize the prefixed 
version, in addition to the unprefixed one, and have all UAs implement 
it.  With that prefix, of course.

2) Some UA ships a prefixed version, sites don't start relying on it, 
the UA can just drop it in favor of the unprefixed version.

3) Some UA ships a prefixed version, then sites start relying on it, 
then that UA removes it after a deprecation period and some evangelism, 
breaking some sites.

4) Some UA ships an unprefixed version, the spec wants to change, but 
sites are relying on the shipped behavior.  The spec uses a different 
name for the changed version, standardizes both versions.  Compare to 
outcome #1.

5) Some UA ships an unprefixed version, the spec changes, sites aren't 
relying on it yet, the UA can just change the behavior.  Compare to 
outcome #2.

6) Some UA ships an unprefixed version, the spec changes, but sites are 
relying on the shipped behavior.  The UA changes to follow the spec, 
breaks the sites.  Compare to outcome #3.

In practice, we've seen some mix of all these outcomes, depending on how 
UAs define "sites depend on this" and their market power in terms of 
getting sites to change and so forth, with both prefixed and unprefixed 
APIs.  Except that there's been huge pushback on UAs implementing "each 
other's" prefixed versions of APIs or standardization of prefixed 
versions, even if UA vendors claim that uses of the prefixed version are 
so widespread that they can't remove it.  The main effect of this 
pushback has been to entrench existing UAs and make more difficult 
creation of new ones, as far as I can tell...

-Boris

On 12/16/13 4:51 PM, Oliver Hunt wrote:
> In my opinion the cost of maintaining an old version of the API may be annoying

It's more than that, if sites are really depending on it.

If sites are depending on it, then it needs to actually be specified, so 
that those sites work in more than one browser engine (and conversely, 
so that new browser engines know they need to implement this old version 
of the API).

What this means in practice one of the following happens:

1. Some UA ships a prefixed version, then sites start relying on it, 
then that UA can't remove it and we need to standardize the prefixed 
version, in addition to the unprefixed one, and have all UAs implement 
it.  With that prefix, of course.

2. Some UA ships a prefixed version, sites don't start relying on it, 
the UA can just drop it in favor of the unprefixed version.

3. Some UA ships a prefixed version, then sites start relying on it, 
then that UA removes it after a deprecation period and some evangelism, 
breaking some sites.

4. Some UA ships an unprefixed version, the spec wants to change, but 
sites are relying on the shipped behavior.  The spec uses a different 
name for the changed version, standardizes both versions.  Compare to 
outcome #1.

5. Some UA ships an unprefixed version, the spec changes, sites aren't 
relying on it yet, the UA can just change the behavior.  Compare to 
outcome #2.

6. Some UA ships an unprefixed version, the spec changes, but sites are 
relying on the shipped behavior.  The UA changes to follow the spec, 
breaks the sites.  Compare to outcome #3.

In practice, we've seen some mix of all these outcomes, depending on how 
UAs define "sites depend on this" and their market power in terms of 
getting sites to change and so forth, with both prefixed and unprefixed 
APIs.  Except that there's been huge pushback on UAs implementing "each 
other's" prefixed versions of APIs or standardization of prefixed 
versions, even if UA vendors claim that uses of the prefixed version are 
so widespread that they can't remove it.  The main effect of this 
pushback has been to entrench existing UAs and make more difficult 
creation of new ones, as far as I can tell...