Le 16/12/2013 22:51, Oliver Hunt a écrit :
(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.
This isn't true. Mozilla clearly intends to stop shipping prefixed
features. Blink made this very clear too.
They both "ship" unprefixed APIs, but hidden behind a flag and/or in
early versions (Canary and Aurora). This systems works well enough, even
for "real" websites whatever you mean by "real".
Parts of WebRTC are currently only shipped in early browser versions and
that allows "real" people to experiment with it and send feedback before
it's considered stable enough to reach the web.
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.
:-/ That's also how you end up with de facto standard of webkit prefixes
in CSS and the aliasing Opera did before the Chromium-based days. It's
likely that the CSS specification will eventually contain the "-webkit-"
properties. This is an unnecessary scar.
How web features arrive in stable versions of browsers changed a lot
since localStorage. I largely prefer a model without prefix and with
early versions. Thanks to Google and Mozilla for their lead in this model!
David
—Oliver
On Dec 16, 2013, at 1:42 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
On Mon, Dec 16, 2013 at 7:01 PM, Andrea Giammarchi
<andrea.giammar...@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
