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
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
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
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
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
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
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
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 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
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
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
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
* 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
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
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
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
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
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?
(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,
.
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
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
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
22 matches
Mail list logo
