(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 <[email protected]> wrote:

> On Mon, Dec 16, 2013 at 7:01 PM, Andrea Giammarchi
> <[email protected]> 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
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to