As you probably know, the ECMA TC39 committee is slowly approaching consensus
on a new revision of the ECMAScript language. The interim results of this
process have gone under various names: Harmony, ES.next, and ES6. They are
the same thing.
Hi Andy, one nit to pick: Harmony is the full
On Dec 16, 2011, at 1:24 AM, Anne van Kesteren wrote:
In general I think versioning is a bad idea, but out-of-band is even
worse.
ES.next is going to have a
use version 6;
in-band pragma.
/be
___
webkit-dev mailing list
Maciej Stachowiak wrote:
On Apr 29, 2012, at 1:25 PM, Ryosuke Niwarn...@webkit.org wrote:
I'm actually curious as to how the session participants reached this consensus
(probably on a separate thread). It seems like the bar shouldn't too high for
removing prefixed APIs when they are
Adam Barth wrote:
On Thu, Jun 7, 2012 at 1:00 PM, Ryosuke Niwarn...@webkit.org wrote:
What is the rationale for adding this property on the navigator object
instead of the chrome object we also expose if your'e not expecting this
property to be ever standarized?
Generally, we avoid
Alice Cheng wrote:
Could you elaborate more on the difference? Maybe the difference is
small enough that it makes sense to reuse all. e.g. Mozilla might
be willing to change their behavior for all.
Mozilla is not selecting atomically using shift + right. It also does
not select atomically
Ojan Vafai wrote:
This isn't spec'ed anywhere. I agree it would be ideal to get a spec
for this, but I don't think we need to block on that in this instance.
This is an area where browsers are completely incompatible already. I
don't see much benefit from blocking on creating a specification
Ryosuke Niwa wrote:
On Mon, Oct 1, 2012 at 5:18 PM, Ojan Vafai o...@chromium.org
mailto:o...@chromium.org wrote:
This is an area where browsers are completely incompatible
already. I don't see much benefit from blocking on creating a
specification to make this situation better for
Geoffrey Garen wrote:
The proposed design requires adding a FooInlines.h include to source files that
use that function, when any function moves into FooInlines.h. This can happen
any time a function is made inline or when a short inline function gets longer.
You convinced me; I hadn't
Filip Pizlo wrote:
On Nov 5, 2012, at 4:15 PM, Brendan Eichbren...@mozilla.org wrote:
Implementation vs. interface distinctions can be fuzzy, but we've found it
helpful to use this as a razor when shaving header files with inlines, before
compile errors or compile time problems bite.
I
Eric Seidel wrote:
However, like those bell-bottoms in your father's closet, RenderArena is back
in vogue and Chromium's security team very excited about
RenderArena's security benefits.
Disco, like the drive-in, will never die.
Brady Eidson wrote:
On Nov 17, 2012, at 7:47 AM, sridharnsridhar.ndr...@gmail.com wrote:
Any updates / plans for this feature ??
What feature?
Sridharn did not cite context, but his message is in the thread whose
head is this post:
I'm stunned that people are arguing this on webkit-dev.
Just FYI, Mozillians with whom I have spoken generally agree that main
does not meet the high bar required to add a new element to HTML.
Shopping a patch to implementors, to get something into a standard spec
by asserting de-facto
Maciej Stachowiak wrote:
[*] If Mozilla on the whole is agains adding this feature, that is relevant new information.
Mozilla as a whole does not often take definitive pro/con positions on
things like main. So I polled a few w3 Mozilla regulars, including
dbaron, tantek, dbolter.
We
13 matches
Mail list logo
