Re: Name of WeakMap
On Mon, Dec 30, 2013 at 10:48 PM, Boris Zbarsky bzbar...@mit.edu wrote: A majority of developers working on mobile web sites, for example. -Boris that's me indeed ... I've been working in major mobile websites since quite a while and I keep saying that not being able to recognize an early implementation from a spec'd one will hit back badly pretty soon both in specs, being unable to do last minute changes to any signature, and for libraries, being unable to feature detect behaviors. Prefixes were a good decision, IMHO, but I do hope I will be proven wrong with real-world careless about prefixes cases. Regards ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
I believe in the future experimental features will stay in modules that can be imported (“import WeakMap from “@weakref-moz-experimental””), making the prefixing problem less critical. In such case, if you want your code to be bullet-proof, you simply do not rely on features marked as experimental. De : Andrea Giammarchi Envoyé : vendredi 3 janvier 2014 11:12 À : Boris Zbarsky Cc : es-discuss On Mon, Dec 30, 2013 at 10:48 PM, Boris Zbarsky bzbar...@mit.edu wrote: A majority of developers working on mobile web sites, for example. -Boris that's me indeed ... I've been working in major mobile websites since quite a while and I keep saying that not being able to recognize an early implementation from a spec'd one will hit back badly pretty soon both in specs, being unable to do last minute changes to any signature, and for libraries, being unable to feature detect behaviors. Prefixes were a good decision, IMHO, but I do hope I will be proven wrong with real-world careless about prefixes cases. Regards___ 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
Re: Name of WeakMap
On 1/3/14 5:12 AM, Andrea Giammarchi wrote: being unable to do last minute changes to any signature Last minute changes are a _bad_ thing. People shouldn't be doing them. The way Blink and Gecko are proceeding at the moment is as follows: 1) Spec draft 2) Implementation, unprefixed, but turned off by default. 3) Turn on the implementation by default in nightly/aurora/canary/dev builds but leave it off in release. 4) Wait until the spec has stabilized. 5) Turn on implementation in release builds. Step 3 allows feedback from people experimenting with the feature while ensuring that it doesn't become used on production sites. After step 5 you typically can't have last-minute changes. At least that's the theory. Prefixes were a good decision It depends on what your goals are. If your goal is to have every site work with every current and future browser, then prefixes obviously fail at that. Of course that's a non-goal for some people, and that's fine; we all have different priorities. but I do hope I will be proven wrong with real-world careless about prefixes cases. I hope you will too, obviously. ;) -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
On 12/17/13 6:55 PM, Andrea Giammarchi wrote: Which library uses window.webkitRequestAnimationFrame before window.requestAnimationFrame and why nobody filed a bug until now? You have three choices, as a library author. Either you don't use the unprefixed version, and then your library somewhat relies on UAs never removing their prefixed versions. Or you use the unprefixed version after the prefixed version, and then your library relies on UAs never removing the prefixed version unless its behavior matches the unprefixed version. Or you use the unprefixed version first, as you suggest, and then your library relies on the unprefixed version having the same behavior as the prefixed version, thus negating the we can change the behavior benefits of prefixing that Oliver brings up. In practice, option 1 is pretty common. For example, jQuery 1.10.2 (and in fact any recent jQuery) does option 1 of these for Element.moz/ie/webkit/oMatchesSelector (not least because there was no unprefixed version really specced), which is why we need to support one of the prefixed versions forever (as long as current jQuery versions are still being used on the web; likely a pretty long time). Similarly, jQuery 1.6.1 does the same thing with requestAnimationFrame, falling back to setTimeout if none of the prefixed versions are supported. GWT versions before 2.5 also use option 1 for requestAnimationFrame. Option 2 is not that uncommon either. For example, jQuery 1.10.2 uses it for element.style.foo access: it first tries prefixed versions like MozFoo and WebKitFoo, before trying foo itself. Modernizr 2.7.1 does some of this too, if I read testPropsAll correctly. Option 3 is sort of used by Prototype 1.7.1.0 for matchesSelector, though it assumes the unprefixed name will be matchesSelector(), not matches(), so in practice it's using option 1. Oh, and it doesn't even use all the vendor prefixes that are relevant for today's browsers. Option 3 is also used in thins like https://gist.github.com/paulirish/1579671 and various other things on the web. Plus I am one of those that hand-craft CSS withe prefixes included and I am happy to deal with prefixes ... which developer uses prefixes everywhere on daily basis without tools? A majority of developers working on mobile web sites, for example. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
On 12/16/13 4:51 PM, Oliver Hunt wrote: In my opinion the cost of maintaining an old version of the API may be annoying It's more than that, if sites are really depending on it. If sites are depending on it, then it needs to actually be specified, so that those sites work in more than one browser engine (and conversely, so that new browser engines know they need to implement this old version of the API). What this means in practice one of the following happens: 1) Some UA ships a prefixed version, then sites start relying on it, then that UA can't remove it and we need to standardize the prefixed version, in addition to the unprefixed one, and have all UAs implement it. With that prefix, of course. 2) Some UA ships a prefixed version, sites don't start relying on it, the UA can just drop it in favor of the unprefixed version. 3) Some UA ships a prefixed version, then sites start relying on it, then that UA removes it after a deprecation period and some evangelism, breaking some sites. 4) Some UA ships an unprefixed version, the spec wants to change, but sites are relying on the shipped behavior. The spec uses a different name for the changed version, standardizes both versions. Compare to outcome #1. 5) Some UA ships an unprefixed version, the spec changes, sites aren't relying on it yet, the UA can just change the behavior. Compare to outcome #2. 6) Some UA ships an unprefixed version, the spec changes, but sites are relying on the shipped behavior. The UA changes to follow the spec, breaks the sites. Compare to outcome #3. In practice, we've seen some mix of all these outcomes, depending on how UAs define sites depend on this and their market power in terms of getting sites to change and so forth, with both prefixed and unprefixed APIs. Except that there's been huge pushback on UAs implementing each other's prefixed versions of APIs or standardization of prefixed versions, even if UA vendors claim that uses of the prefixed version are so widespread that they can't remove it. The main effect of this pushback has been to entrench existing UAs and make more difficult creation of new ones, as far as I can tell... -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
On Mon, Dec 16, 2013 at 6:06 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: 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 No, that's not how it works. You support something as long as significant amounts of content depend on it, so you don't break pages. The existence of a replacement doesn't mean that everyone immediately updates their pages to the new method. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
The real-world out there always tries to address the potential standard and use these prefixed methods as fallbacks, not vice versa. It would be very unwise to rely prefixed methods only in production and I am not sure who does it but yes, the dropping might be gradual notifying in console that has been deprecated. Having the same unstable, not standard yet, global native constructor is a problem in these fields: 1. documentation ... MDN has been promoted as the place to document JavaScript ... MDN has many Mozilla and Gecko only methods and properties ... does MDN want to include every possible quirk for every possible method that every browser might or might not have implemented in a slightly different, since not standard yet, way? If the answer is NO, it's fragmentation of the documentation ... which I believe is not useful for anyone 2. User Agent sniffing will be promoted instead of impossible features detections 3. signatures implemented too early will lead to shenanigans 4. every early implementation either will break the web the day it will change or will create an absurd mess of extra code to understand if it's the one that works as expected or not (again, leads to UA sniffing) A very concrete example about prefixes, and since you work on this daily, is the CSS gradient background syntax: http://css-tricks.com/css3-gradients/ Now imagine that scenario with JavaScript ... a constructor that has different signatures and no way to tell if it was an early adoption or the standard version if not through User Agent sniffing ... and since the race to early adopt any sort of thing is the biggest part of the modern Browsers war, who do you honestly think will benefit from such decision? I understand that at the time Chromium decided to branch out from WebKit, going to the press saying yeah, another blok prefix is coming would have been bad ... press speaking, but at the same time almost nobody uses anymore pure CSS and prefixes there are handled automatically plus many use utilities such lo-dash or others so that behavior are ensured behind the scene and nobody really care if that function was prefixed or not. What do we have as pros avoiding prefixes instead? Does that overcome all these cons? Best Regards On Tue, Dec 17, 2013 at 10:00 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Mon, Dec 16, 2013 at 6:06 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: 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 No, that's not how it works. You support something as long as significant amounts of content depend on it, so you don't break pages. The existence of a replacement doesn't mean that everyone immediately updates their pages to the new method. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
On Tue, Dec 17, 2013 at 12:43 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: The real-world out there always tries to address the potential standard and use these prefixed methods as fallbacks, not vice versa. That's not true. almost nobody uses anymore pure CSS and prefixes there are handled automatically That isn't either. Not even close. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
Are you able to provide Pros of the non prefixed decision or that's all you have to say about it? Not even a link? How useful has your answer been for anyone? Which library uses window.webkitRequestAnimationFrame before window.requestAnimationFrame and why nobody filed a bug until now? Plus I am one of those that hand-craft CSS withe prefixes included and I am happy to deal with prefixes ... which developer uses prefixes everywhere on daily basis without tools? 'cause at least I try to group via classes and use as less as possible. Thanks On Tue, Dec 17, 2013 at 2:41 PM, Jason Orendorff jason.orendo...@gmail.comwrote: On Tue, Dec 17, 2013 at 12:43 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: The real-world out there always tries to address the potential standard and use these prefixed methods as fallbacks, not vice versa. That's not true. almost nobody uses anymore pure CSS and prefixes there are handled automatically That isn't either. Not even close. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Name of WeakMap
At the last f2f2 we talked about renaming WeakMap to SideTable. We postponed the discussion, saying that we would get back to it later. We never did. I would like us to keep the name WeakMap as it is. We didn't really take WeakSet into account. If we rename WeakMap we would need to rename WeakSet too and I like the current Map/Set analogy. -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
On Mon, Dec 16, 2013 at 11:59 AM, Erik Arvidsson erik.arvids...@gmail.comwrote: At the last f2f2 we talked about renaming WeakMap to SideTable. We postponed the discussion, saying that we would get back to it later. We never did. I would like us to keep the name WeakMap as it is. We didn't really take WeakSet into account. If we rename WeakMap we would need to rename WeakSet too and I like the current Map/Set analogy. I'll second this with the added comment that after four weeks, SideTable doesn't sound any better or worse than WeakMap. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
Brendan and I had a side conversation the next day we should have brought to the attention of the group. In the main discussion, we said we needed to hear back from Luke, since WeakMap had already shipped in IE11. The next day we did, and Brendan I agreed to drop the renaming. Which, fortunately, is also in agreement with Arv and Rick. WeakMap / WeakSet it is. On Mon, Dec 16, 2013 at 12:16 PM, Rick Waldron waldron.r...@gmail.comwrote: On Mon, Dec 16, 2013 at 11:59 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: At the last f2f2 we talked about renaming WeakMap to SideTable. We postponed the discussion, saying that we would get back to it later. We never did. I would like us to keep the name WeakMap as it is. We didn't really take WeakSet into account. If we rename WeakMap we would need to rename WeakSet too and I like the current Map/Set analogy. I'll second this with the added comment that after four weeks, SideTable doesn't sound any better or worse than WeakMap. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
* Erik Arvidsson wrote: At the last f2f2 we talked about renaming WeakMap to SideTable. We postponed the discussion, saying that we would get back to it later. We never did. I would like us to keep the name WeakMap as it is. We didn't really take WeakSet into account. If we rename WeakMap we would need to rename WeakSet too and I like the current Map/Set analogy. (The name SideTable makes me think I seriously need to re-evaluate what `WeakMap` is supposed to be.) -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
It seems to me that once again early adoption of non complete standards wins in the short term, compromising the long one forever ... Although IE11 promised incremental updates too and create an alias on the global scope is not the end of the world, IMO. 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. And yes IE team, the prefix would lowercase as any other Browser is doing, thanks. Just my 2 cents. Best Regards On Mon, Dec 16, 2013 at 9:23 AM, Mark S. Miller erig...@google.com wrote: Brendan and I had a side conversation the next day we should have brought to the attention of the group. In the main discussion, we said we needed to hear back from Luke, since WeakMap had already shipped in IE11. The next day we did, and Brendan I agreed to drop the renaming. Which, fortunately, is also in agreement with Arv and Rick. WeakMap / WeakSet it is. On Mon, Dec 16, 2013 at 12:16 PM, Rick Waldron waldron.r...@gmail.comwrote: On Mon, Dec 16, 2013 at 11:59 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: At the last f2f2 we talked about renaming WeakMap to SideTable. We postponed the discussion, saying that we would get back to it later. We never did. I would like us to keep the name WeakMap as it is. We didn't really take WeakSet into account. If we rename WeakMap we would need to rename WeakSet too and I like the current Map/Set analogy. I'll second this with the added comment that after four weeks, SideTable doesn't sound any better or worse than WeakMap. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ 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
Re: Name of WeakMap
as the horse rightly pointed out ... please let me reformulate last sentence: And yes IE team, the prefix would be lowercase as any other browser is doing, thanks. ( no MSWhateverItIs, thanks!) On Mon, Dec 16, 2013 at 11:01 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: It seems to me that once again early adoption of non complete standards wins in the short term, compromising the long one forever ... Although IE11 promised incremental updates too and create an alias on the global scope is not the end of the world, IMO. 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. And yes IE team, the prefix would lowercase as any other Browser is doing, thanks. Just my 2 cents. Best Regards On Mon, Dec 16, 2013 at 9:23 AM, Mark S. Miller erig...@google.comwrote: Brendan and I had a side conversation the next day we should have brought to the attention of the group. In the main discussion, we said we needed to hear back from Luke, since WeakMap had already shipped in IE11. The next day we did, and Brendan I agreed to drop the renaming. Which, fortunately, is also in agreement with Arv and Rick. WeakMap / WeakSet it is. On Mon, Dec 16, 2013 at 12:16 PM, Rick Waldron waldron.r...@gmail.comwrote: On Mon, Dec 16, 2013 at 11:59 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: At the last f2f2 we talked about renaming WeakMap to SideTable. We postponed the discussion, saying that we would get back to it later. We never did. I would like us to keep the name WeakMap as it is. We didn't really take WeakSet into account. If we rename WeakMap we would need to rename WeakSet too and I like the current Map/Set analogy. I'll second this with the added comment that after four weeks, SideTable doesn't sound any better or worse than WeakMap. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ 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
Re: Name of WeakMap
On Dec 16, 2013, at 9:34 AM, Bjoern Hoehrmann wrote: ... (The name SideTable makes me think I seriously need to re-evaluate what `WeakMap` is supposed to be.) That is what was so attractive about changing the name. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
The problem i have with SideTable as a name is that it’s implying a very specific use case (one that could equally be served by private names), it’s also not an obvious name to developers who are not aware of terms of art. I said a long time ago that the name WeakMap did not match the expected semantics of other languages, nor what was expected by developers but we couldn’t think of a good alternative name, and (i thought) decided that sticking with WeakMap was the best of the bad options. —Oliver On Dec 16, 2013, at 1:09 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Dec 16, 2013, at 9:34 AM, Bjoern Hoehrmann wrote: ... (The name SideTable makes me think I seriously need to re-evaluate what `WeakMap` is supposed to be.) That is what was so attractive about changing the name. Allen ___ 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
Re: Name of WeakMap
Le 16/12/2013 22:42, Anne van Kesteren a écrit : 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). Or don't put it in the spec at all? David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
(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 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
Re: Name of WeakMap
On Mon, Dec 16, 2013 at 4:42 PM, Oliver Hunt oli...@apple.com wrote: The problem i have with SideTable as a name is that it’s implying a very specific use case (one that could equally be served by private names), it’s also not an obvious name to developers who are not aware of terms of art. I said a long time ago that the name WeakMap did not match the expected semantics of other languages, nor what was expected by developers but we couldn’t think of a good alternative name, and (i thought) decided that sticking with WeakMap was the best of the bad options. Several of us, including myself, have been repeatedly surprised at how much confusion the term WeakMap has caused. SideTable may or may not be a bit better, but it doesn't matter. Given existing practice and the lack of a compelling need to rename, it is too late. —Oliver On Dec 16, 2013, at 1:09 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Dec 16, 2013, at 9:34 AM, Bjoern Hoehrmann wrote: ... (The name SideTable makes me think I seriously need to re-evaluate what `WeakMap` is supposed to be.) That is what was so attractive about changing the name. Allen, SideTable actually perpetuates most of the confusion caused by the term WeakMap, though not all. SideTable still encourages one to think as-if the mutable storage is in the map/table, rather than being hung off the key objects. That's why it is only a bit better. The Relationship term you mentioned that led to http://wiki.ecmascript.org/doku.php?id=strawman:relationships is still the only term that suggests the right way to think about this, but would be terrible as the name of the abstraction. Allen ___ 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 -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
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
Re: Name of WeakMap
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
andrea.giammar...@gmail.com 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 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
