(I know Anne knows this argument, but i’m emailing this logic for people who aren’t aware of it)

The reason for prefixing APIs is to allow a feature to be shipped and used by developers before the final api semantics are settled on.  In the event the spec doesn’t change then they simply alias, but if the spec does change it allows an engine to continue to maintain the old behaviour in the prefixed API and so not break any content that depends on the API.

Saying that you should never ship anything if it would need prefixing means that you can never see real examples of usage because no _real_ site is going to use a feature that isn’t available in actual shipping browsers.  If the API is not prefixed then once it ships and is used it can never be fixed under the same name (see localStorage being stuck with a string backing store).  That’s why prefixed APIs exist — it’s not so we can say the API is unstable, it’s so that the API can be changed once developers have started using preliminary versions.

In my opinion the cost of maintaining an old version of the API may be annoying, but is vastly outweighed by the ability to put features in the hands of authors without forcing the API to be stuck with it’s early draft semantics.

—Oliver


On Dec 16, 2013, at 1:42 PM, Anne van Kesteren <annevk at annevk.nl> wrote:

> On Mon, Dec 16, 2013 at 7:01 PM, Andrea Giammarchi
> <andrea.giammarchi at gmail.com> wrote:
>> We are all use to write abominations such `var url = window.webkitURL ||
>> windows.mozURL || windows.URL` and similar stuff all over, the reason
>> utilities libraries are often preferred, so while I am very happy that IE
>> team finally has been able to catch up and be even in front of other
>> browsers, I do believe that incomplete specifications or those still under
>> discussion should be adopted with prefixes until finalized in their form in
>> order to promote less mistakes in the long term.
> 
> That way you end up with e.g. having to support mozMatchesSelector()
> forever in addition to matches(). We're certainly going to avoid doing
> that in Gecko.
> 
> If you're unclear on the name, just make it clear in the specification
> that the name is not stable and that therefore it cannot ship yet (you
> could implement it and ship it in nightlies and such of course).
> 
> 
> -- 
> http://annevankesteren.nl/
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

(I know Anne knows this argument, but i’m emailing this logic for people who aren’t aware of it)

The reason for prefixing APIs is to allow a feature to be shipped and used by developers before the final api semantics are settled on.  In the event the spec doesn’t change then they simply alias, but if the spec does change it allows an engine to continue to maintain the old behaviour in the prefixed API and so not break any content that depends on the API.

Saying that you should never ship anything if it would need prefixing means that you can never see real examples of usage because no _real_ site is going to use a feature that isn’t available in actual shipping browsers.  If the API is not prefixed then once it ships and is used it can never be fixed under the same name (see localStorage being stuck with a string backing store).  That’s why prefixed APIs exist — it’s not so we can say the API is unstable, it’s so that the API can be changed once developers have started using preliminary versions.

In my opinion the cost of maintaining an old version of the API may be annoying, but is vastly outweighed by the ability to put features in the hands of authors without forcing the API to be stuck with it’s early draft semantics.