Re: ES8 Proposal: Optional Static Typing (Brandon Andrews)
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 continued for all types, including the TypedArrays (if not already being considered). I personally like this pattern because it doesn't change typeof, and it provides an less-verbose alternative, and it is able to be polyfilled because it's an API addition and not a syntax change. Note https://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/thread.html#msg105 where this was discussed previously and not really met with acceptance. -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Will any new features be tied to constructors?
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 are normal subclassed objects, they would just call super() from the constructor to set the browser-supplied bits and then add whatever else is needed themselves. Or are you saying that super() would fully allocate the object and prevent adding new private state (or other features tied to constructors)? -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Will any new features be tied to constructors?
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 else is needed themselves. Yes, that is the Dmitry proposal. This is confusing. The Element.create callback from Dmitry can also be called post-construction, so it's strictly different from most subclassing scenarios. Apparently Kevin and Allen's private state proposal is based on private state being installed at allocation time, so yes, since super() fully allocates the object, this would prevent private state for custom elements. So are you saying that would make private state harder to use for any kind of subclassing scenario? -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Will any new features be tied to constructors?
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 if not being lexically part of the constructor was fine, you could still not depend on it being invoked at the same time. -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Will any new features be tied to constructors?
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 that Dmitry's design depends on not executing JavaScript while constructing the element. Whereas if you put this[Element.init]() in the constructor it totally would. -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Will any new features be tied to constructors?
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. It's explained in some detail in this email: https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0230.html What's wrong with inserting a deferred custom element node into the DOM when you initially parse and then replacing it with an actual custom element instance of the correct class when when the script it depends upon has been loaded? There's some rationale on this page: https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0230.html In brief, you might lose added event listeners, gets complicated with attributes and children, mutation observers will be somewhat spammy. Domenic and Dimitry might be able to elaborate more. -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Will any new features be tied to constructors?
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 state slots are allocated when the object is created. But in your use case you wouldn't know what slots to allocate until after you've created the object. And then it's too late. Right, my personal preference is to just use constructors. That however has two drawbacks: 1) Leaves upgrading nodes up to the developer. Or requires them to load script synchronously, blocking the parser. Neither is particularly great. 2) Would allow JavaScript to run while cloning nodes (needed for various editing operations and printing in some browsers) would be a pain as the C++ algorithms are not prepared for it. Very much unclear if that's feasible within any reasonable amount of time. -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Will any new features be tied to constructors?
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 the script to load lazily while the parser continues running. However, if the user agent always invokes the constructor, would that exclude us from new features? E.g. I could imagine private data properties to be an allocation affair of sorts. (Note: I'm not personally pushing this design, I'm just exploring the consequences.) To clarify, since this was not completely clear, the question is whether anything other than object allocation will be allowed only through a constructor? That is, do any JavaScript language designers have plans to restrict certain object functionality to constructors, or will constructors only ever be responsible for object allocation and nothing else? The answer to this question would greatly impact the way we make DOM extensible. And given that we plan to decide on that in three weeks time any quick answer would be appreciated. Thanks! -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Will any new features be tied to constructors?
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 agent always invokes the constructor, would that exclude us from new features? E.g. I could imagine private data properties to be an allocation affair of sorts. (Note: I'm not personally pushing this design, I'm just exploring the consequences.) -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Putting `global` reference in specs
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 reference the global object is not nearly enough. -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promises vs Streams
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 https://mail.mozilla.org/listinfo/es-discuss
Re: How to fix the `class` keyword
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. https://www.youtube.com/watch?v=hneN6aW-d9w on how to contribute more effectively. Proposing grand design changes when ES6 is done when you don't really have established credibility is unlikely to do you any favors. If you prefer reading, https://annevankesteren.nl/2014/03/contributing-to-standards has some tips as well. -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Cancelable promises
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 from the user. I think they decided to postpone for now until there's a bit more progress on what cancelable promises means, but I would not expect everyone to wait forever. -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How would we copy... Anything?
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 should not be considered. -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: classes and enumerability
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 quite a while now. It's rather frustrating TC39 keeps ignoring the feedback given while at the same time complaining that DOM and IDL are so different. -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Sharing a JavaScript implementation across realms
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 think) not hard to answer. Burdened malloc/GC heap full cost, not net estimate from source analysis, would be best. Cc'ing Nick, who may already know. Thanks, Well, I heard that for e.g. B2G we moved from JavaScript workers to C++ threads due to memory constraints. It might well be that this is a solvable problem in JavaScript engines with sufficient research, it's just at the moment (and in the past) it's been blocking us from doing certain things. -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Sharing a JavaScript implementation across realms
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 efficient. If we want to get further with turning the web platform into a giant JavaScript library, we need to tackle this somehow. Has anyone been thinking about how to do this and what changes it would require from JavaScript proper? We're now at the point where we can implement platform objects in terms of JavaScript, but JavaScript loses out due to lack of efficiency. PS: Alternative explanation available here: https://annevankesteren.nl/2015/01/javascript-web-platform -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Any news about the `module` element?
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 so they could later be upgraded to be module compatible without requiring some new out-of-band switch. It hasn't really gotten much traction unfortunately. -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Relationship between globals, Realms, and global environment records
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 first place, so that HTML has less reason to correct ES. -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Relationship between globals, Realms, and global environment records
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 a different global environment record after it has been initialized. How would you test whether all three of them have changed? Note that the ES6 spec. defines InitializeFirstRealm [1] that define how the first Realm gets created. Creating additional realms would have to perform a similar set of steps. http://people.mozilla.org/~jorendorff/es6-draft.html#sec-initializefirstrealm -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Relationship between globals, Realms, and global environment records
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)
console.log(self.x) // undefined
}
--
https://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Relationship between globals, Realms, and global environment records
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: https://esdiscuss.org/topic/let-this-object-of-global-environment-be-specified-by-host https://esdiscuss.org/topic/realm-api-and-this-global https://bugs.ecmascript.org/show_bug.cgi?id=1898 :-( (That said, it's still unclear to me why we need to have three constructs to describe one object.) -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Relationship between globals, Realms, and global environment records
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 object. It's not currently defined in excruciating detail, but I suspect it will be at some point since content depends on this working. Should that affect the Realm and global environment record? Yes, imo. I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=27419 to track this on the HTML side. -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Relationship between globals, Realms, and global environment records
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 this working. Should that affect the Realm and global environment record? -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: async/await improvements
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. -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: async/await improvements
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 particular idea is that it'd require that we somehow encode the concept of window.onerror and/or the console (etc) into the spec -- which currently has no notion of these things. http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/thread.html#msg24 It seems in scope for the specification that defines window.onerror... Someone is working on standardizing parts of the console API as well. I think it's required these days since it leaked on the web... -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Late shadowing of globals, esp. 'undefined'?
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 capabilities between globals defined through JavaScript libraries and the browser? 2) While document, navigator, etc. are non-configurable and whatnot, there's a bunch of other host defined globals that have different characteristics. Just study Window's IDL in HTML. -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Holy mixed metaphors, Batman!
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/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Event loops in navigated-away-from windows
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 wouldn't change the implementations. The proposed setup from Allen will start failing the moment ECMAScript wants something more complicated with its loop. At that point you'll have to propose another set of hacks to make the integration with HTML work again. And given this integration is so weird, I doubt implementations will match it as written. Seems more likely they'll implement the more straightforward alternative. (Also, the proposed setup does seem to require exactly that kind of mental integration I was worried about. With HTML hijacking the ES loop to do its bidding.) -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Event loops in navigated-away-from windows
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. Given that the Host has a more complicated model, that would be much saner and wouldn't cause all this confusion of jobs vs microtasks vs tasks. -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Event loops in navigated-away-from windows
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 Microsoft. What would it do at
a specification level?
--
https://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Event loops in navigated-away-from windows
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 event loop concept, ECMAScript added another and now I somehow mentally need to integrate them. It would be way clearer if ECMAScript just queued tasks/jobs/microtasks to the Host so we'd keep a single concept of a loop. -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Event loops in navigated-away-from windows
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 browsing context's event loop have an associated document.
If that document is not fully active, those tasks are skipped when
selecting the oldest task to run for that event loop. Meaning that if
you navigate away the tasks for the document you navigated away from
stop executing, until you navigate back to it.
https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-9
covers this processing model.
--
https://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: My ECMAScript 7 wishlist
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 anObject.saysWhat();
what
https://bugzilla.mozilla.org/show_bug.cgi?id=683218 is the bug on
getting it removed, in case anyone is interested.
--
https://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: import script -- .esm
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 default browser loader which is still secret(?) purportedly standardizes on a js suffix. That is probably why this came up. (I think text/javascript is just fine btw. text/* works great for HTML and CSS too. In any event, for the purposes of the browser JavaScript does not really have a MIME type. We parse anything we get...) -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: import script -- .esm
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 work but I don't see how you can accurately guess without some sort of hint that you need to parse as module. I suspect the mode switching will happen on the client. E.g. script type=module is one such proposed way. module (with various unresolved XSS issues) is another. Within the browser environment workers are another type of JavaScript environment, although we do not parse them differently at the moment. (There's a suggestion that service workers become strict by default though so we can upgrade them to be modules more easily.) -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use strict VS setTimeout
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/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use strict VS setTimeout
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 opinions beside what specs say) Everyone should be able to post there just fine, you don't even need to subscribe. The only thing you need to take into account if it is really your first time is that you need to give the W3C permission to republish your email (the first time you post you get an email about that). And that first time it'll take a bit longer therefore for your email to reach the list and archives. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Questions regarding ES6 Unicode regular expressions
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 proposals. As far as I can tell that hasn't changed. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Importing modules inside HTML imports
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 personally think that would be great. It seems you did not read what I wrote. CSP does support inline scripts these days. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Importing modules inside HTML imports
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 https://w3c.github.io/webappsec/specs/content-security-policy/ for the new nonce-source and hash-source features. (Don't read TR/, it's kind of equivalent to reading the previous version of ES, but worse.) -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Importing modules inside HTML imports
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 either, but it is what it is). That doesn't ring true. CSP didn't, but does now based on feedback that not having inline scripts was too painful. I very much doubt they will go away anytime soon. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Early error on '0' followed by '8' or '9' in numeric literals does not seem to be web-compatible
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 immaterial.) -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Should / Can an EventHandler throw a stack overflow exception?
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. :( Paging Allen. If defining this needs to start anywhere, it would probably be ECMAScript. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A way of explicitly reporting exceptions
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 defines that code path (how it ends up in window.onerror and such). Cross-referenced this thread. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: @@new
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 revisited and modified as needed. Revisiting existing classes and making them suitable for subclassing seems like something that would be hard to avoid. Allen had to do it for all the built-in classes to make sure certain methods return this.constructor and such, I doubt we're going to avoid that. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
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 as easily imagine the HTML parser doing all the work and stripping the new comment forms from the token stream. No, that would be bad for debuggers. ECMAScript just has to suck this up (I think a bug is already filed and pending a fix), just like CSS has. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
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 place? Is that the constrain? (If it is, removing !--/-- weirdness would indeed be good.) I suspect in part this depends on where we allow module as well. If we make it generic like template and script, tablemodule/table would no longer have the element end up before the table element, but rather inside (and unclosed until EOF). -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
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 question: Does such an old browser consider the table to be closed by this occurrence of /table? Yes and yes. I recommend playing with http://software.hixie.ch/utilities/js/live-dom-viewer/ if you do not want to read the algorithm in the specification. The tree it generates might surprise you. Be sure to switch out module with script for differences ;-) -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 5 June 2014 TC39 Meeting Notes
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 becoming a previous sibling rather than a child. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `this` inside modules
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 for an external opt-in flag for modules. E.g. making service workers use strict mode as suggested in https://github.com/slightlyoff/ServiceWorker/issues/294 would no longer allow us to safely upgrade them to module syntax later on. Per https://www.w3.org/Bugs/Public/show_bug.cgi?id=25868 it is argued that use modules would be bad UX, but that seems to be exactly where this is heading, except the syntax is outside of JavaScript. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Integrating the Webs' dependency systems
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 post. He wants to reconcile them with ES6 Modules. I get the impression you are talking about something else. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Integrating the Webs' dependency systems
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. I don't even know what this means. You are aware it's mostly browsers that are on TC39 right and drive JS implementation? -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Integrating the Webs' dependency systems
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 we know precisely where we want to draw the line of how much loading logic is to be provided by JS and specced by TC39, vs provided by a hosting environment and specced by those that spec that specific hosting environment? Probably not. Right, that is the issue. If you look at the web platform there's many different types of resources. Images, style sheets, media, scripts, ... There's a couple of solutions being thought of for dependency management, stipulated by Ian. It would be nice if we got to something more coherent for web developers. But if the issue is of general interest across many hosting environments, then it should probably be handled by JS and TC39, rather than duplicating work among the hosting environment specs. What other hosting environment has similar characteristics to loading of web pages? -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Integrating the Webs' dependency systems
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 mean the underlying Fetch mechanism. Could you elaborate on exactly how this would work? Would this be in the layer before or after Service Workers? Supposing that a page has both a service worker and a custom loader, I would expect all requests for URL’s in the page (href, src, etc) to 1. pass through the page’s loader 2. pass through the browser's fetch mechanism 3. pass through the service worker Only http/https URL fetches enter the service worker. 4. pass through the browser's fetch mechanism again This depends on what the service worker does. It might instead perform its own fetches (using fetch()) which presumably would go through the service worker's loader if we were to define that as such (it having its own global environment). The service worker might also pop back up to fetch and let it handle the fetch (not handling the fetch event) or might indeed pass it through fetch (using event.default()). It might also return a generated response or some such. 5. possibly arrive at the true service The HTTP layer you mean I guess. 6… proxies all the way down? I suppose you could further divide the HTTP layer. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ArrayBuffer neutering
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 https://github.com/dslomov-chromium/ecmascript-structured-clone is picked up TC39 should probably develop an overarching strategy for these kind of objects. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
ArrayBuffer neutering
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:
http://software.hixie.ch/utilities/js/live-dom-viewer/
script
var a = new ArrayBuffer(12)
onmessage = function(e) { w(e.data); w(e.data.byteLength); w(a);
w(a.byteLength) }
postMessage(a, http://software.hixie.ch;, [a])
/script
The above will log:
object [object ArrayBuffer] (0 props)
12
object [object ArrayBuffer] (0 props)
0
And not throw a TypeError as suggested.
--
http://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ArrayBuffer neutering
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 http://www.khronos.org/registry/typedarray/specs/latest/ and search for neutered it seems relatively clear. byteLength returns 0 and the other members follow from there. Is this behavior actually specified anywhere. If not, do all significant browsers implemented this behavior. Does web content depend upon it. (What use could be made of knowing the (former) length of a neutered ArrayBuffer. What I tested seems to be specified and implemented by Firefox, Safari, and Chrome. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: bugs.ecmascript.org problem?
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 modification has happened. (I *do* get a response for all my other requests.) Is anyone else seeing this? Maybe it's an idea to just get a component here: http://www.w3.org/Bugs/ That could be easily arranged. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: HTML date format and Date.parse()
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 to 15.9.1.15 (allow a space in place of 'T') and an equally minor change to 15.9.1.15.1 (extended years), plus a sentence or two of rationale. The proposal has nothing to do with the unspecified legacy formats. I agree it'd be nice to get the intersection of those formats documented, but it's a tangent. For that reason, it would probably be better to define static methods for parsing specific formats. For example, Date.parseHTMLDate(str) //only recognizes whatever HTML defines The reason I propose changing 15.9.1.15 is to have one *less* thing to remember. To unify, since we actually have an opportunity to do that here, for once! Why is it important to have Date.parse(2013-01-01 10:30Z) return NaN? Can we please reconsider this? Getting HTML and ES more aligned would be *so* nice :-) -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Realm API and this != global
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 really fulfill its intended use as iframe without DOM. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: standardizing Error.stack or equivalent
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 object, returns the stack. That way, code which does not have access to the getStack function cannot see the stacks. Given the existing API which we cannot remove, isn't it too late for that? Why would we want the asymmetry? -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.contains
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/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
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 more spec-compliant than either of the shipping implementations? In particular, we support subclasses. It will take a long time before browsers support subclassing in general as far as I can tell. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
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 ahead and shipping promises in Firefox 29. Too many dependencies at this point to hold of longer. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
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 broke. Mozilla can probably still make things in order before promises hit stable. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Specification styles
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 help in understanding the bug in the promises specification. I suspect not everyone here is familiar with what you are referring to. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Operator overloading for non-value objects
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 took after a / Location and what existing URL libraries offered, and nobody has questioned that design much to date. It is implemented now in Firefox/Chrome though. URLSearchParams is mutable and that's definitely desired. So if we still want to expose equivalent functionality we'd have to provide a readonly variant of that. We could at some point provide a URLValue API maybe for immutable URLs (and have operator overloading). -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Operator overloading for non-value objects
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 something like url.equals(url2) or URL.equal(url, url2) or url.toString() == url2.toString() is somewhat Java-esque. Is that what we should do? And if so, opinions on which variant? -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Operator overloading for non-value objects
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. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Operator overloading for non-value objects
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 sometimes write .equals() (non-value objects, method name won't always be the same, e.g. we have isEqualNode() already). I guess for now we should just go with url.equals(url2) then and see where that takes us. (Alex feels more strongly about this than I do.) -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
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 Standard, I think the only strong tie to the DOM at this point is its usage of DOMException. I have a few times on this list tried to figure out what the right way forward is for exceptions within the web platform so that they still fit well within the ES universe, but none of those led anywhere satisfactory yet. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
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: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23971 -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
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 major Web platform dependency I see is the use of DOMString and associated attributes such as [EnsureUTF16]. Those shouldn't be there for a host environment independent spec. Sure, that's easily mapped though. (The whole EnsureUTF16 thing is in need of fixing in IDL.) But overall, it shouldn't be hard to fix these things and make it completely independent of the web platform. It could drop quite nicely into the new TC39 process model it you wanted to go that route of standardization. Agreed. I don't really have the bandwidth at the moment to work on this though. I have fixed the examples: https://github.com/whatwg/encoding/commit/da5d1426a4e7ff7c7fea6724957b2c70df09bce4 -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
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 implemented using JS couldn't use S.p.trim to process labels as described in the spec. [1]: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.trim http://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-string.prototype.trim This seems more than a nit! You cannot use that method for CSS, HTML, HTTP, etc. either. For this API we could have a different definition of whitespace I suppose, but e.g. for meta charset=... I doubt we could do that without risking breakage (or at the HTML parser level, say). -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
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 TextDecoder and TextEncoder constructors. So, it isn't clear how CSS or anything else is relevant to that. As I said, the algorithm used to get an encoding is also used by HTML, CSS et al. See e.g. http://dev.w3.org/csswg/css-syntax/#input-byte-stream and http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#determining-the-character-encoding -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
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 this from? Google and Mozilla have implemented the API from http://encoding.spec.whatwg.org/ as a means to get strings out of bytes (and bytes out of strings). It's not clear we need anything else. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [Json] Encoding detection (Was: Re: JSON: remove gap between Ecma-404 and IETF draft)
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. XHR's responseType = json only supports UTF-8 (optionally with a leading BOM), across the board. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules vs Scripts
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/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JSON: remove gap between Ecma-404 and IETF draft
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 b) Process the rest according to rfc4627bis or ECMA-404 (whichever works better if they are not in full alignment). That will make sure that variation is confined as locally as possible. So that is roughly how it is defined. Using the web's utf-8 text resource decode method that removes a BOM and then passing the rest to something equivalent to JSON.parse(). However, if we are defining a new text transport format I think it would make sense to allow a leading BOM similar to how text/css, text/html, etc. allow for that. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
JSON: remove gap between Ecma-404 and IETF draft
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 parsing 42 as an error, which is a far more unlikely scenario than parsing it as 42 given precedence. (Worth pondering about: what to do about a leading BOM, which XMLHttpRequest and browsers allow, but neither IETF nor Ecma-404 allow.) -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JSON: remove gap between Ecma-404 and IETF draft
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 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 parsing 42 as an error, which is a far more unlikely scenario than parsing it as 42 given precedence. (Worth pondering about: what to do about a leading BOM, which XMLHttpRequest and browsers allow, but neither IETF nor Ecma-404 allow.) -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Cross-global instanceof
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 of a method or something else. It's not
really clear why sometimes you would use if brand in obj and other
times Array.isArray(obj). Seems rather messy.
--
http://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Cross-global instanceof
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 introduce something like Object.crossGlobalInstanceOf(instance, type) which checks @@crossGlobalBrand or some such which works for built-ins and is also usable by jQuery and the like. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 draft, Rev20 is now available
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 now first test for @@iterator and then fall back to the legacy behavior. If there are web APIs that currently accept array-likes and you don't do this then you are really to accept a lower bar for backward compatibility than what TC39 has been willing to accept. That is not the problem. The problem is that when designing ES it seems like you are not considering the web ecosystem that exists around ES and how that might need to adapt to changes in the underlying language. Or in other words, the language does not exist in a vacuum, yet it feels like you are designing it in that way. This may very well be a perception and communication problem and I think we are making progress towards addressing it, but please keep that in mind. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 draft, Rev20 is now available
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/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 draft, Rev20 is now available
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 ok. Right? An array-like only length and properties 0, 1, ... as far as I know. I thought iterable meant they implement the iterator protocol. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 draft, Rev20 is now available
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 WebIDL. I expect we can. Anne, do you want to post to public-script-coord about this, or should I? https://www.w3.org/Bugs/Public/show_bug.cgi?id=23683 (I mostly asked here first since the other breaking changes to IDL to align with JavaScript haven't been very popular. But maybe this is indeed small enough to get away with.) -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 draft, Rev20 is now available
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 wants to accept a sequenceT it only needs it to have an @@iterator if it is actually going to use JS iterator semantics to process. There is no reason that an implementation of such a consuming API couldn't do its own fall back to non-iterator based iteration. That would be a non-breaking solution. This is about the accepting side, not returning. The idea was for that was to be the same as the spread operator. Of course we could do something else and have it compatible with current IDL semantics, but that's not very coherent, nor desirable long term. So either the spread operator changes or we change sequenceT. Going forward it'd be great if we tried to reason about these things platform-wide, rather than JavaScript-wide. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ArrayClass should imply @@isConcatSpreadable
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_ changing the concat() behavior of these should be OK. Certainly for .ports, which we haven't been shipping for very long at all. Thoughts? Could we still change those to actual arrays? I guess for .ports that might be trickier as it implies a readonly view. ArrayClass feels like a hack. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Working with grapheme clusters
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 they would mistakenly use them with the intended meaning of `String.prototype.graphemeAt` and `String.prototype.graphemes` as discussed in the present message? Thoughts? I think you're correct. If we want to make it easier for developers to work with text, we should offer them functionality at the grapheme cluster level and not distract everyone with code units and code points. Thanks for making a proposal! -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Working with grapheme clusters
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 points, cause those are the units you end up escaping individually. Is that really a common operation? I would expect formatting, searching, etc. to dominate. E.g. whenever you do substr/substring you would want that to be grapheme-cluster aware. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
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 codePointAt() as that would fail for input with paired surrogates. E.g. a simple loop over a string that prints code points would print both the code point and the trail surrogate code point for a surrogate pair. The same goes for this new method. I still think that only offering a better way to iterate strings (as planned) seems like a much safer start into this brave new code point-based world. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
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() as that would fail for input with paired surrogates. E.g. a simple loop over a string that prints code points would print both the code point and the trail surrogate code point for a surrogate pair. I disagree. In those situations you should just iterate over the string using `for…of`. That seems to iterate over code units as far as I can tell. for (var x of ) print(x.charCodeAt(0)) invokes print() twice in Gecko. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Multiple globals and changing prototypes
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 in different global objects. Event handlers and custom elements make this somewhat more tricky and we're discussion how to work with them in the bug. The reason we want to change prototypes is to reduce the potential for memory leaks and give consistent behavior across nodes in a tree. I.e. they'll always be from the same global. (There's also the more complicated document.open() scenario, which we should discuss separately at some point I think, but for those trying to figure out how to define multiple realms in ECMAScript that's worth looking into.) -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generic Bundling
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. That doc is a bit cryptic. Can you explain how new URL syntax to address a ZIP member (I like, we had it in the ancient days with JAR files [ZIPs of course] using '!') avoids updating both end points? The content on the server starts using script src=assets.zip!lib/main.js/script How do old browsers cope? The idea is to use a somewhat more unique separator, e.g. $sub/. Old browsers would simply fetch the URL from the server and if the server is written with legacy in mind would serve up the file from there. New browsers would realize it's a separator and fetch the URL up to the separator and then do addressing within the zip archive once its retrieved. https://gist.github.com/wycats/220039304b053b3eedd0 has a more complete summary of our current thinking. (Not entirely up to date.) -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: FYI: Ecma-404 approved and published
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 that it's Unicode). It wasn't entirely clear to me whether that comment made it all the way. Looks good. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: FYI: Ecma-404 approved and published
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 that it's Unicode). It wasn't entirely clear to me whether that comment made it all the way. Looks good. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Comments on Sept Meeting Notes
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 so nice as HTMLCollection gets around. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Comments on Sept Meeting Notes
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 HTMLCollection for the reason you mention. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
