no prefix and early versions is a mess to feature detect too ... if two
engines offer same name and different signature or functionality you need
to feature detect at runtime which one is correct and this is **not walys
possible**
A clear example is IndexedDB or anything that trigger the ultra-annoying
top thingy in Firefox that asks permission for ... as it is, lately even
for localStorage.
Same name incomplete globals means dealing with a weak User Agent sniffing
over "pretending" functionality while this means that what is returned
first, is what I can expect and hopefully correct by specs:
`var raf = window.requestAnimationFrame || window.mozRequestAnimationFrame;`
I can eventually understand if a prefix was used then decide that if the
non prefixed version is there the behavior of that method or that browser
is "X"
In this case I don't know if WeakMap is the IE11 one or the partially
implemented in Chrome with experimental flags ... how much difficult all
this has to be for developers?
I thought features detection were the way to go ... unified names with any
sort of early signature adoption on top is a nice theory that does not work
in practice, imho.
We'll see more and more pointless UA sniffing, being unable to know if the
updated version of the same browser did eventually fix that constructor or
not ... not even a [experimental Function] instead of [native Function] as
{}.toString.call I guess, right?
I know there's no perfect solution but prefixes have been a very practical
one that worked.
Libraries can use prefixes once ... browsers can alias final globals with
prefixes without problems, if these where OK so that matches() or
mozMatchSelectos() will be basically the same function.
Best Regards
On Mon, Dec 16, 2013 at 2:07 PM, David Bruant <bruan...@gmail.com> wrote:
> 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
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
