last thought would be an answer to th epossible question: do we need to support mozMatchSelector forever ?
NO since matches() will do once it works as standards say br On Mon, Dec 16, 2013 at 3:26 PM, Andrea Giammarchi < [email protected]> wrote: > 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 <[email protected]> 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 <[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 >>> >> >> _______________________________________________ >> 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
