On Sun, Jul 19, 2015 at 10:05 PM, Ron Waldon jokeyrh...@gmail.com wrote:
We've seen a new pattern in ES5 and continued now with ES2015:
- Array.isArray()
- Number.isNumber()
- Object.isObject()
- etc...
I can only find the first in this list.
Perhaps this pattern just needs to be
On Wed, Jul 1, 2015 at 2:50 PM, Domenic Denicola d...@domenic.me wrote:
I.e., do you see any plausible world in which you're allowed to create a
custom element with a custom allocator, instead of the browser-supplied
HTMLElement one?
I'm not sure I follow. In a world where custom elements
On Wed, Jul 1, 2015 at 3:49 PM, Domenic Denicola d...@domenic.me wrote:
From: Anne van Kesteren [mailto:ann...@annevk.nl]
In a world where custom elements are normal subclassed objects, they would
just call super() from the constructor to set the browser-supplied bits and
then add whatever
On Wed, Jul 1, 2015 at 10:56 AM, Domenic Denicola d...@domenic.me wrote:
Dmitry's design does *not* depend on that. In fact Dmitry's design includes
this[Element.init]() in the constructor.
Fair, but it does depend on that not always being invoked at the same
time as the constructor. So even
On Wed, Jul 1, 2015 at 2:54 AM, Domenic Denicola d...@domenic.me wrote:
Stated another way, which might be a bit stronger: will it be *lexically*
required that private state initialization be within the constructor, or will
it only be *temporally* required?
I don't see how this matters given
On Tue, Jun 30, 2015 at 5:54 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
How would your hypothetical early allocated objects be observably exposed?
The design is basically that the browser first creates a normal
element, and at a later point changes the prototype and invokes the
callback.
On Tue, Jun 30, 2015 at 6:41 PM, Kevin Smith zenpars...@gmail.com wrote:
Changes the prototype dynamically? We're generally moving away from such
shenanigans.
That would indeed interact poorly with some of the designs for private state
that we've been entertaining. In such a scheme private
On Sat, Jun 27, 2015 at 2:21 AM, Anne van Kesteren ann...@annevk.nl wrote:
For custom elements in DOM there's a proposal to have the constructor
be controlled by the user agent and have some kind of callback that
actually initiates the element. This has some advantage in that it
allows
For custom elements in DOM there's a proposal to have the constructor
be controlled by the user agent and have some kind of callback that
actually initiates the element. This has some advantage in that it
allows the script to load lazily while the parser continues running.
However, if the user
On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
So I'd say we should not have `self` (if stays on global and Worker I don't
actually care) and add a `global` that nobody needs explanation to
understand what it is in JavaScript
Indeed, three ways to
On Sat, Mar 28, 2015 at 1:14 PM, Boopathi Rajaa legend.r...@gmail.com wrote:
Why do we have both?
Why do we have both values and arrays, not just the latter?
--
https://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
On Wed, Mar 4, 2015 at 1:23 PM, Eric Elliott e...@paralleldrive.com wrote:
I know I've raised all these issues on es-discuss before and basically been
told to go suck an egg, but we all want the same thing -- a better
JavaScript for everybody.
I recommend watching e.g.
As a heads up, there's some debate around the fetch() API how exactly
request termination should work and how that affects promises:
https://github.com/slightlyoff/ServiceWorker/issues/625
The WebRTC WG has also been discussing canceling in the context of
terminating a request for permission
On Mon, Feb 23, 2015 at 10:10 AM, Michał Wadas michalwa...@gmail.com wrote:
My proposition is to create a new well known Symbol - Symbol.clone and
corresponding method on Object - Object.clone.
Anything that does not deal with
https://github.com/dslomov-chromium/ecmascript-structured-clone
On Fri, Jan 30, 2015 at 7:44 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Developers have to understand they cannot `new HTMLDivElement()` anyway and
they cannot extend WebIDL interfaces in JS world neither.
That will change.
bz and others have been working on bridging the gap for
On Wed, Jan 14, 2015 at 1:28 AM, Brendan Eich bren...@mozilla.org wrote:
Before we go tl;dr on this topic, how about some data to back up the
asserted problem size? Filip gently raised the question. How much memory
does a realm cost in top open source engines? Fair question, empirical and
(I
A big challenge with self-hosting is memory consumption. A JavaScript
implementation is tied to a realm and therefore each realm will have
its own implementation. Contrast this with a C++ implementation of the
same feature that can be shared across many realms. The C++
implementation is much more
On Sun, Dec 21, 2014 at 5:42 PM, James Burke jrbu...@gmail.com wrote:
(I am
sure you are aware of the coming Service Worker bliss, so not just a
curious side issue):
I and some others have been advocating for service workers to run in
strict mode by default, as well as having this be undefined
On Wed, Nov 26, 2014 at 1:48 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Given that ES6 doesn't have a public Realm API it really doesn't make much
difference.
Why not? Currently HTML overrides to make the existing setup work...
That's the whole reason we wanted to change this in the
On Tue, Nov 25, 2014 at 1:51 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
There is definite a 1:1:1 relationship between a global object, realmRec,
global environment record. And ES views those relationships are immutable.
You can't just change the global object of a realmRec or give it
On Tue, Nov 25, 2014 at 5:45 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
I'm simply trying to understand what what is meant when HTML talks about
changing the global object/realm/etc.
onload = function() {
self.x = test
console.log(self.x) // test
document.open(text/html)
On Tue, Nov 25, 2014 at 8:48 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
It would be trivial to change the ES spec. to allow for the script this
binding and global object to be set to independent value when a Realm is
created.
Yeah, you said so in 2013 as well, yet nothing happened:
On Sat, Nov 22, 2014 at 10:42 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/22/14, 6:20 AM, Anne van Kesteren wrote:
I thought these to be 1:1:1, but e.g. HTML defines the document.open()
API
https://html.spec.whatwg.org/multipage/webappapis.html#dom-document-open
which replaces the global
I thought these to be 1:1:1, but e.g. HTML defines the document.open()
API https://html.spec.whatwg.org/multipage/webappapis.html#dom-document-open
which replaces the global object. It's not currently defined in
excruciating detail, but I suspect it will be at some point since
content depends on
On Thu, Nov 13, 2014 at 1:57 AM, Jeff Morrison lbljef...@gmail.com wrote:
Note that in my crazy idea I didn't say rethrow -- I carefully called it
out as more of a log than a throw.
I thought the plan was to have something equivalent to window.onerror
for promises.
--
On Thu, Nov 13, 2014 at 7:13 PM, Jeff Morrison lbljef...@gmail.com wrote:
I think that's what this discussion is about. Such a log could be
dispatched to window.onerror as well as console (etc).
Coming back to this after sleeping on it, though: The biggest problem I can
think of with my
On Wed, Oct 29, 2014 at 1:53 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
I suppose we could extend that to include all built-in globals. Could really
do it for host defined globals.
1) I thought the idea was that host defined would be a thing of the
past. Do we want differences in
On Fri, Oct 17, 2014 at 6:23 AM, Brendan Eich bren...@mozilla.org wrote:
Again this sub-thread, is mostly about finding the right terms of art. If we
can unify across specs (if not within), that's gravy.
Vat helps explaining workers, but not the rest.
--
https://annevankesteren.nl/
On Mon, Sep 29, 2014 at 8:18 PM, Ian Hickson i...@hixie.ch wrote:
I certainly wouldn't object to the ES spec's event loop algorithms being
turned inside out (search for RunCode on the esdiscuss thread above for
an e-mail where I propose this) but that would be purely an editorial
change, it
On Sat, Sep 27, 2014 at 4:03 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Now that JS is growing an event loop, what should happen to it in
navigated-away-from windows?
I still don't understand why JavaScript needs to have the loop itself
and can't just queue jobs for the Host to take care of.
On Sat, Sep 27, 2014 at 3:52 PM, Mark S. Miller erig...@google.com wrote:
What happens if someone runs
(function f() {setImmediate(f);})();
in a web page?
As far as I can tell from
https://developer.mozilla.org/en-US/docs/Web/API/Window.setImmediate
that seems like a proprietary API from
On Sat, Sep 27, 2014 at 3:54 PM, Mark S. Miller erig...@google.com wrote:
What confusion is being caused? AFAICT, this change is causing only the
clarification of things that were/are confusing, such as Boris' question.
Well, I for one find it confusing that while HTML had a fairly worked
out
On Sat, Sep 27, 2014 at 4:02 PM, Mark S. Miller erig...@google.com wrote:
My intent was not to refer to a nonstd api. Instead, what happens with
(function f() {setTimeout(f, 0);})();
in a web page that is navigated away from?
Now we get to why having two loops is bad...
Tasks in a
On Fri, Sep 26, 2014 at 5:01 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
On Thu, Sep 25, 2014 at 6:56 PM, Boris Zbarsky bzbar...@mit.edu wrote:
SpiderMonkey used to support __noSuchMethod__, I believe.
It's still there.
js var anObject = { __noSuchMethod__() { return what; } };
js
On Wed, Sep 10, 2014 at 6:14 PM, Brendan Eich bren...@mozilla.org wrote:
RFC4329 rightly favors application/ -- but this is all beyond the scope of
ECMA-262. Do Not Want TC39 deciding suffixes. Let developers develop
conventions. (Just so long as they do not sound like skin diseases.)
Well the
On Wed, Sep 10, 2014 at 6:23 PM, Matthew Robb matthewwr...@gmail.com wrote:
The problem is that there are now two distinctly different types of
javascript file, some should be parsed as script and some should be parsed
as module. Assuming everything is script that is not explicitly module would
On Sun, Sep 7, 2014 at 7:29 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I know this is probably W3C land ...
First hit for callback use strict inurl:lists.w3.org:
http://lists.w3.org/Archives/Public/public-script-coord/2011JulSep/thread.html#msg3
--
http://annevankesteren.nl/
On Sun, Sep 7, 2014 at 9:06 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Yes Anne, reason I've posted here was to ask opinions from JS land + I am
not sure it's that easy to post in W3C mailing list as random chap while
here I'm already registered (and here I was looking for
On Mon, Aug 25, 2014 at 11:44 AM, Till Schneidereit
t...@tillschneidereit.net wrote:
(Forwarding to Norbert as I don't know how closely he follows es-discuss.)
I think last year somewhere regular expression extensions were
postponed because nobody was interested in working out detailed
On Sun, Aug 17, 2014 at 8:52 PM, John Barton johnjbar...@google.com wrote:
The argument goes like this: we all want secure Web pages, we can't secure
Web pages that allow inline scripts, therefore we have to ban inline
scripts.
If the argument is wrong, ignore my advice, CSP will die. I
On Mon, Aug 18, 2014 at 4:57 PM, John Barton johnjbar...@google.com wrote:
So you are claiming that CSP no longer restricts inline scripts and that the
various online docs are incorrect? Or only that the server set the
unsafe-inline value to opt out of the restriction?
Neither. See
On Sat, Aug 16, 2014 at 2:46 AM, John Barton johnjbar...@google.com wrote:
As we noted in another thread, Web devs no longer control servers. And
servers no longer allow inline script (for the most part going forward). So
I don't see this feature as worth investing effort in. (I don't like it
On Thu, Aug 7, 2014 at 11:59 PM, Brendan Eich bren...@mozilla.org wrote:
This doesn't mean strict mode failed. It does mean no-mo'-modes.
Except for modules? (As they definitely require a mode switch
(module instead of script). Perhaps at a higher-level than
JavaScript, but that seems
On Mon, Jun 30, 2014 at 6:01 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/30/14, 4:40 AM, Anne van Kesteren wrote:
Are stack overflow exceptions even a thing per standards?
No.
However, they come up pretty regularly in practice. In fact, some sites
depend on them for proper functioning
On Mon, Jun 23, 2014 at 8:54 PM, Boris Zbarsky bzbar...@mit.edu wrote:
So what I'd like to propose is some API that takes a value and routes it
through the codepath uncaught exceptions get sent through.
I just filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=26182 on
HTML since it actually
On Wed, Jun 18, 2014 at 9:01 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Note that at this point we're already forcing spec authors to think about
the exact @@create behavior to make things subclassable and that in
particular, every single existing spec that has a constructor will need to
be
On Fri, Jun 13, 2014 at 6:06 PM, C. Scott Ananian ecmascr...@cscott.net wrote:
To some degree the line between the HTML parser and Web EcmaScript is
movable; currently the HTML parser recognizes the `!--` etc tokens
but pushes them into the data section of the script tag anyway; one
could just
On Fri, Jun 13, 2014 at 6:31 PM, Mark S. Miller erig...@google.com wrote:
Does there exist any string where an old browser using old rules would
decide that a module is closed at one place, but a new browser following
the rules you propose would decide that the module is closed at a
different
On Fri, Jun 13, 2014 at 6:45 PM, Mark S. Miller erig...@google.com wrote:
Hi Anne, I didn't understand the answer. When an old browser that knows
nothing of module specifically sees tablemodule/table, does it
consider the module to be closed when it sees the /table ? This also
raises the
On Fri, Jun 13, 2014 at 6:57 PM, Rick Waldron waldron.r...@gmail.com wrote:
To be clear, you're referring to the automatic placement of module as a
descendant of BODY even if it's explicitly written inside head/head (but
not for script)?
That is a similar effect. My example was about it
On Mon, Jun 9, 2014 at 6:25 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
The current proposal would instead create a
world where `this` is about methods most of the time, but is a magic ambient
variable in some cases (sloppy scripts, modules).
This also creates an ever bigger need
On Thu, May 29, 2014 at 3:09 AM, John Barton johnjbar...@google.com wrote:
Perhaps my explanation was unclear; I have nothing to say about browser
implementation.
That's the only part Ian is interested in. He helps authoring the
standards for the various features he mentioned in the initial
On Thu, May 29, 2014 at 4:40 PM, John Barton johnjbar...@google.com wrote:
My intuition is that any such plan would be vigorously opposed by the JS
community. Or perhaps vigorously ignored: browsers are falling behind
current technology and are no longer in a position to dictate what JS means.
On Thu, May 29, 2014 at 5:12 PM, Mark S. Miller erig...@google.com wrote:
That said, I'm not really sure what this argument is about. Should we grow
the ES6 module loading mechanism so that it can better handle the loading of
other resources beside JS code that is relevant to JS? Probably. Do
On Wed, May 28, 2014 at 12:29 AM, Kris Kowal kris.ko...@cixar.com wrote:
On Tue, May 27, 2014 at 3:04 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 May 2014, Kris Kowal wrote:
It would be lovely if HTML could be trained to resolve URL's through the
module system.
By HTML here I presume you
On Wed, May 21, 2014 at 2:10 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Why didn't you provide a isNeutered predicate?
Note that per
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#transferable
there's more objects that can be neutered. Once
ArrayBuffer instances whose [[ArrayBufferData]] is null are
considered to be neutered However, most algorithms only check for it
being undefined (and sometimes missing).
In addition, the behavior defined seems incompatible with what is in browsers:
On Tue, May 20, 2014 at 5:25 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
The ES6 TypedArray/ArrayBuffer spec. was written closely following the
Khronos spec. which is pretty vague about what happens when an ArrayBuffer
is neutered.
If you go through
On Tue, Apr 29, 2014 at 12:40 AM, Michael Dyck jmd...@ibiblio.org wrote:
For the past couple of days, when I create or modify a bug on
bugs.ecmascript.org, my browser doesn't get a response. I know
the requests are being received, because when I check via another
tab, the creation or
On Wed, May 1, 2013 at 5:45 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
On Tue, Apr 30, 2013 at 4:34 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
ES6 annex B is the appropriate place to define browser host web reality
extensions to Date.parse.
I'm proposing a one-line change
Given that we now expose realms to JavaScript, fixing this mismatch
between HTML and JavaScript seems somewhat more important (although
really, HTML explicitly overriding JavaScript should be a big warning
sign): https://bugs.ecmascript.org/show_bug.cgi?id=1898 Otherwise, the
Realm API cannot
On Thu, Mar 27, 2014 at 4:31 PM, Mark Miller erig...@gmail.com wrote:
The stack should not be accessible given only the error object. Rather,
there should be a getStack function
https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#300
which, given an error
On Wed, Mar 5, 2014 at 11:19 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Personally I think the more useful model to follow than
`String.prototype.contains` is `Set.prototype.has`.
That would not allow us to kill DOMStringList.
--
http://annevankesteren.nl/
On Fri, Feb 14, 2014 at 10:50 PM, C. Scott Ananian
ecmascr...@cscott.net wrote:
Since both Chrome and FIrefox have plans to support Promises, feel
free to suggest any changes to `es6-shim` which would improve
compatibility. It looks like that at the moment the `es6-shim`
implementation is
On Fri, Feb 7, 2014 at 11:50 AM, Anne van Kesteren ann...@annevk.nl wrote:
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=966348 on Gecko
when the news broke. Mozilla can probably still make things in order
before promises hit stable.
To be clear, we fixed this. And we will be going
On Fri, Feb 7, 2014 at 12:45 PM, Yutaka Hirano yhir...@chromium.org wrote:
Sorry for knowing little about ES consensus, is this the final decision?
Will you change it again?
Yeah, some clarity would be nice.
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=966348 on Gecko
when the news
On Thu, Jan 30, 2014 at 10:55 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Unfortunately, the promise specification doesn't handle incumbent/entry
settings objects either, so the behavior is undefined no matter what. :( It
needs to.
Could you maybe give an explicit example? I think that would
On Wed, Jan 15, 2014 at 7:35 AM, Sebastian Markbåge
sebast...@calyptus.eu wrote:
At risk of derailing the conversation with a tangent... I don't understand
the premise. Why is it so important that URLs are mutable? (Other than
already being drafted that way.)
That's a good question. I mostly
In a discussion I had with Alex Russell as how to do comparison for
URL objects it ended up with desiring
url == url2
to work. It escaped me at that point that I already discussed this
briefly and Brendan explained why face-to-face. However, I forgot what
he said :/
The alternative, either
On Mon, Jan 13, 2014 at 1:47 PM, Claude Pache claude.pa...@gmail.com wrote:
I haven't found mention of `toString` or `valueOf` in the WHATWG URL spec
(http://url.spec.whatwg.org/), although I may have missed the feature.
Web IDL named it stringifier. I recommend filing bugs on browsers.
--
On Mon, Jan 13, 2014 at 3:40 PM, Brendan Eich bren...@mozilla.com wrote:
We want to keep the relatively few invariants in the language that we have.
Why is it so important to have == for (mutable) URLs?
The alternative is rather ugly. You don't want to sometimes write ==
(value objects) and
On Fri, Jan 10, 2014 at 7:00 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
[...] it might be reasonable to have a solution that isn't tied to a specific
environment.
Agreed. I have argued the same for URL parsing
http://url.spec.whatwg.org/ at some point.
As for the API in the Encoding
On Fri, Jan 10, 2014 at 9:40 PM, Boris Zbarsky bzbar...@mit.edu wrote:
OK, so specify ISO-8859-1, if that's what you're really doing.
Note that iso-8859-1 maps to windows-1252. There is an open bug on
exposing a label to the API that has the real iso-8859-1 behavior:
On Sat, Jan 11, 2014 at 5:27 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
There are a couple places where a string such as EncodingError is thrown.
We'd never do that and would use either TypeError or RangeError.
If you follow the link for throw, you'll find it's a DOMException.
The
On Sat, Jan 11, 2014 at 5:57 PM, Brendan Eich bren...@mozilla.com wrote:
Allen Wirfs-Brock wrote:
Another nit: the definition of ASCII whitespace is different from the
definition of whitespace used by String.prototype.trim [1]. That means that
an implementation of this spec. that was
On Sat, Jan 11, 2014 at 6:37 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
I'm only talking about this specification and what it takes to decouple it
from web platform dependencies. In this case, ASCII whitespace seems to only
be used in processing the label parameter passed to the
On Fri, Jan 10, 2014 at 6:22 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
https://bugs.ecmascript.org/show_bug.cgi?id=1557 is a request that
StringView [1] over ArrayBuffers be added to ES.
[1]
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays/StringView
Where is
On Thu, Nov 21, 2013 at 1:35 PM, Henri Sivonen hsivo...@hsivonen.fi wrote:
UTF-32 harms JSON interchange, because Gecko removed all UTF-32
support throughout the engine (other engines probably did, too, but
I'm too busy to check) and, therefore, XHR responseType = json
doesn't support UTF-32.
On Sun, Nov 17, 2013 at 2:23 PM, Matthew Robb matthewwr...@gmail.com wrote:
I like it. If there is a desire to stay closer to script I could see
script module and script module=
Has to be script type=module otherwise it would execute in legacy clients.
--
http://annevankesteren.nl/
On Tue, Nov 12, 2013 at 5:20 PM, Martin J. Dürst
due...@it.aoyama.ac.jp wrote:
If XMLHttpRequest has reasons to continue allowing it, I'd suggest that:
1) It strongly discurages it, and
2) It defines processing as something roughly like
a) If the first few bytes look like a BOM, ignore them
To improve JSON interoperability the IETF should not define a more
restricted version of JSON than defined by Ecma-404.
Parsers exist that can parse 42 today and parsers that cannot parse
42 today can be meaningfully upgraded to do so too. This would not
break those parsers, unless they depend on
To be clear, this is a Last Call comment on
http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-07 The JSON Data
Interchange Format (draft-ietf-json-rfc4627bis-07).
On Tue, Nov 12, 2013 at 3:01 PM, Anne van Kesteren ann...@annevk.nl wrote:
To improve JSON interoperability the IETF should
On Fri, Nov 1, 2013 at 12:50 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
[isSpecialString]() {return isSpecialString in this};
So this is basically what we have for DOM objects right now. And what
we're asking for is having this elevated to language-supported
construct. Be it in the form
This keeps coming up. Last instance:
http://mxr.mozilla.org/mozilla-central/source/dom/base/ObjectWrapper.jsm#16
We have it for Array using Array.isArray(). It is unclear why the
arguments for arrays not apply to other types of objects, such as
array buffers, nodes, blobs, files, etc.
We could
On Wed, Oct 30, 2013 at 7:52 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
I don't understand what is special about the web APIs in this regard. On the
accepting side in ES we generally allow no breaking changes. Wherever there
was an existing API that accepted old-style array likes we
On Tue, Oct 29, 2013 at 4:50 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Spread now requires an Iterable rather than an array-like
This is different from how sequenceT behaves in IDL. (It uses array-likes.) :/
--
http://annevankesteren.nl/
On Wed, Oct 30, 2013 at 5:14 PM, Brendan Eich bren...@mozilla.com wrote:
Anne van Kesteren wrote:
This is different from how sequenceT behaves in IDL. (It uses
array-likes.) :/
This is more general, since array-likes should be iterable to be like
arrays, which are iterable.
So this seems
On Wed, Oct 30, 2013 at 7:01 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/30/13 2:28 PM, Allen Wirfs-Brock wrote:
Those are the sort of objects, that we decided to explicitly exclude
from spread and for-of.
Sure. The question is whether we can compatibly exclude them from
sequenceT in
On Wed, Oct 30, 2013 at 7:23 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Doesn't really depend upon the usage. If an API is going to return a
sequenceT to JS code, it really should have an @@iterator. But that is
presumably a non-breaking change, from the JS perspective. If an API
On Mon, Oct 28, 2013 at 8:20 PM, Boris Zbarsky bzbar...@mit.edu wrote:
In terms of existing ArrayClass objects that are shipping on the web right
now, Gecko is shipping (though perhaps not in final releases yet) the .ports
of a MessageEvent and the return value of getClientRects(). I _think_
On Thu, Oct 24, 2013 at 3:02 PM, Claude Pache claude.pa...@gmail.com wrote:
As a side note, I ask whether the `String.prototype.symbolAt
`/`String.prototype.at` as proposed in a recent thread,
and the `String.prototype[@@iterator]` as currently specified, are really
what people need,
or if
On Thu, Oct 24, 2013 at 3:31 PM, Mathias Bynens math...@qiwi.be wrote:
Imagine you’re writing a JavaScript library that escapes a given string as an
HTML character reference, or as a CSS identifier, or anything else. In those
cases, you don’t care about grapheme clusters, you care about code
On Fri, Oct 18, 2013 at 1:46 PM, Mathias Bynens math...@qiwi.be wrote:
Similarly, `String.prototype.charCodeAt` is fixed by
`String.prototype.codePointAt`.
When you phrase it like that, I see another problem with
codePointAt(). You can't just replace existing usage of charCodeAt()
with
On Fri, Oct 18, 2013 at 4:58 PM, Mathias Bynens math...@qiwi.be wrote:
On 18 Oct 2013, at 10:48, Anne van Kesteren ann...@annevk.nl wrote:
When you phrase it like that, I see another problem with
codePointAt(). You can't just replace existing usage of charCodeAt()
with codePointAt
I believe last time this came up here some people hard concerns so I
was wondering whether that was still the case and what alternatives
there might be.
In https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567 we're
considering to define the behavior Gecko exhibits when moving a node
between trees
On Sun, Oct 13, 2013 at 8:30 PM, Brendan Eich bren...@mozilla.com wrote:
Anne van Kesteren mailto:ann...@annevk.nl
It would require each end point that wants to support this to have new
syntax. A solution from http://wiki.whatwg.org/wiki/Zip#URLs will not
require updating all the end points
On Tue, Oct 8, 2013 at 7:59 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
The Ecma General Assembly has approved by letter ballot Ecma-404: THE JSON
Data Interchange Formal
See http://www.ecma-international.org/publications/standards/Ecma-404.htm
I'm glad the alphabet is now defined (and
On Tue, Oct 8, 2013 at 7:59 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
The Ecma General Assembly has approved by letter ballot Ecma-404: THE JSON
Data Interchange Formal
See http://www.ecma-international.org/publications/standards/Ecma-404.htm
I'm glad the alphabet is now defined (and
On Sat, Sep 28, 2013 at 10:14 PM, Kevin Smith zenpars...@gmail.com wrote:
Would you agree that HTMLCollection is an inherently future-hostile API?
That is, it is impossible to add *any* methods or properties to the API
without potentially breaking compatibility?
Right, which is why symbols are
On Mon, Sep 30, 2013 at 12:12 PM, Brendan Eich bren...@mozilla.com wrote:
Yes, for naming meta-level stuff.
For naming methods, not nice. This limits future additions.
I think all we want here is make HTMLCollection interoperate better
with other lists. For new features we moved away from
1 - 100 of 236 matches
Mail list logo
