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
Hi,
Exploring how web browsers implement Array.protototype.sort, I've found two
patterns:
On the one hand, Firefox (SpiderMonkey) and IE (Chakra) have three distinct
phases:
1. Get the values from the target, in ascending order of the keys (from 0 to
the length exclusively) (using
Do you have any examples of real-world issues caused by this difference? If
not, I don't think we should spec the behavior of .sort any more than it is
right now. (Well, I'd argue for requiring a stable sort, but then that's
easy for me as an implementor working on an engine that already has a
Le 18 août 2014 à 12:59, Till Schneidereit t...@tillschneidereit.net a écrit :
Note also that, by my reading of the spec at least, all implementations
currently fully adhere to the spec: they [p]erform an
implementation-dependent sequence of calls to the [[Get]] and [[Set]]
internal
On Mon, Aug 18, 2014 at 1:32 PM, Claude Pache claude.pa...@gmail.com
wrote:
Le 18 août 2014 à 12:59, Till Schneidereit t...@tillschneidereit.net a
écrit :
Note also that, by my reading of the spec at least, all implementations
currently fully adhere to the spec: they [p]erform an
On Mon, Aug 18, 2014 at 12:57 AM, Anne van Kesteren ann...@annevk.nl
wrote:
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
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 Mon, Aug 18, 2014 at 8:02 AM, Anne van Kesteren ann...@annevk.nl wrote:
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
So today I was thinking about the possibility of having the module instance
object be a function. If it were a function with fairly simple code to
check if the default exports is also a function and if so then apply-invoke
it then you would have a much more useful module instance object.
If you
To avoid overly spamming the list I've coallesced my responses to various
threads over the weekend into this one e-mail.
On Fri, 15 Aug 2014, John Barton wrote:
But since the only way the client can know that it needs a.js
and jquery.js is if the server tells it [...]
On Wed, 13 Aug 2014, Ian Hickson wrote:
One of the problems I'm running into when it comes to trying to
integrate ES6 modules with HTML and new HTML-based dependency features
is the way that I can't tell ES about dependencies I know about before
the data is actually fetched and
On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson i...@hixie.ch wrote:
To avoid overly spamming the list I've coallesced my responses to various
threads over the weekend into this one e-mail.
I really think this makes the discussion more difficult to follow and
certainly more difficult to
On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 15 Aug 2014, John Barton wrote:
On Fri, Aug 15, 2014 at 3:41 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 15 Aug 2014, John Barton wrote:
The ES Loader does not maintain a dependency tree. It maintains a
John, you can also use SPDY/HTTP2.0 PUSH to send sticky code alongside with the
original HTML that will mimic the use of inline scripts but behaves like an
external script. Essentially, you will have: `script
src=/my-sticky-data-and-initialization-per-page.js/script`, while that
script is
Sounds promising, but the key use case cited by Brendan is ease-of-use so
it's important that all of this happens by default as far as Web devs are
concerned.
On Mon, Aug 18, 2014 at 11:23 AM, caridy car...@gmail.com wrote:
John, you can also use SPDY/HTTP2.0 PUSH to send sticky code alongside
I created the following gist as a proposal for the addition of a `finally`
method to the prototype of the Promise constructor, either for ES6 (if such a
thing is considered valuable and could be fast tracked at this date), or for
ES7. This method would take in a single callback that would be
Here is the current design for Promise.prototype.finally. I agree it is a
useful feature.
https://github.com/domenic/promises-unwrapping/issues/18
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Yes. Needed it recently.
Ended up doing .then(f).catch(f) which can be survived but feels stupid.
David
Le 18/08/2014 21:20, Domenic Denicola a écrit :
Here is the current design for Promise.prototype.finally. I agree it is a
useful feature.
On Mon, Aug 18, 2014 at 10:55 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 13 Aug 2014, Ian Hickson wrote:
One of the problems I'm running into when it comes to trying to
integrate ES6 modules with HTML and new HTML-based dependency features
is the way that I can't tell ES about
On Mon, Aug 18, 2014 at 12:30 PM, David Bruant bruan...@gmail.com wrote:
Yes. Needed it recently.
Ended up doing .then(f).catch(f) which can be survived but feels stupid.
And doesn't have the correct pass-through behavior, unless you've got
a switch in f that makes it return or throw based on
On Mon, 18 Aug 2014, John Barton wrote:
On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 15 Aug 2014, John Barton wrote:
On Fri, Aug 15, 2014 at 3:41 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 15 Aug 2014, John Barton wrote:
The ES Loader does not
On Mon, 18 Aug 2014, John Barton wrote:
On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson i...@hixie.ch wrote:
To avoid overly spamming the list I've coallesced my responses to
various threads over the weekend into this one e-mail.
I really think this makes the discussion more difficult to
On Mon, Aug 18, 2014 at 2:00 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 18 Aug 2014, John Barton wrote:
On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 15 Aug 2014, John Barton wrote:
On Fri, Aug 15, 2014 at 3:41 PM, Ian Hickson i...@hixie.ch wrote:
On
On Mon, Aug 18, 2014 at 2:06 PM, Ian Hickson i...@hixie.ch wrote:
Now, in the main page, you reference the HTML import:
link rel=import href=foo.html
Now how would you refer to the modules? We can't have #b refer to
it, since the scope of IDs is per-document,
Domenic,
I like the addition that your version of `finally` can itself return a Promise,
which I hadn't considered (as I hadn't had a need for it myself yet). Is the
consensus that this won't make it into Promise until at least ES7, and then
only if there's enough of a call for it?
To be
Is the consensus that this won't make it into Promise until at least ES7, and
then only if there's enough of a call for it?
Although I find the arbitrary division of features into ES6 and ES7
distasteful personally: yes, ES6 will not be adding new APIs. That doesn't mean
that
Would there be any problems treating the html import as a virtual module
itself. Giving all scripts inside the sub document the module context
object as its this binding? Then to do any additional loading you'd need to
do this.import().
On Aug 18, 2014 6:56 PM, John Barton johnjbar...@google.com
On Mon, Aug 18, 2014 at 5:32 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 18 Aug 2014, John Barton wrote:
...
But in the case of image tags we already know exactly which image the
HTML depends upon.
But other elements might depends on the img, and that we don't know.
(For example, a
Background:
http://esdiscuss.org/topic/next-yo-in-newborn-generators
http://esdiscuss.org/topic/april-8-2014-meeting-notes
It appears that the current state of affairs is that the argument supplied
to the first call of `next` on a newborn generator is ignored and
inaccessibe.
Clearly, this
29 matches
Mail list logo