Hi.
I must admit I didn't follow the whole thread about native element
proxyfication but when I left the consensus was that the native element should
not be proxied (ie: it would not work like Object.create(...) do not work for
them).
I've however a compelling use case that may make some of
Le 31/01/2013 16:10, François REMY a écrit :
Hi.
I must admit I didn't follow the whole thread about native element
proxyfication but when I left the consensus was that the native element should
not be proxied (ie: it would not work like Object.create(...) do not work for
them).
Just to
Let's say I want to implement a polyfill for MapEvent whose definition is
as follows:
interface MapEvent : Event {
getter any item(DOMString name);
}
Out of curiosity, where does MapEvent come from? I can't remember having
read about it on any spec and Google isn't helping.
Just to
Le 31/01/2013 17:26, François REMY a écrit :
I think such a getter notation exists in WebIDL to formalize scars from
the past (like HTMLCollection) rather than to be used in new APIs
Yes and no. For exemple, something alike is envisionned to support custom
properties in CSS. Something like:
I think such a getter notation exists in WebIDL to formalize scars from
the past (like HTMLCollection) rather than to be used in new APIs
Yes and no. For exemple, something alike is envisionned to support custom
properties in CSS. Something like:
element.style.myCustomProperty = true;
Le 31/01/2013 18:34, François REMY a écrit :
I think such a getter notation exists in WebIDL to formalize scars from
the past (like HTMLCollection) rather than to be used in new APIs
Yes and no. For exemple, something alike is envisionned to support custom
properties in CSS. Something like:
In this instance, it's possible for you as a polyfill author to replace
Element.prototype.style by your own getter which returns your special
proxy objects which do what you expect on property set.
For the style case, it's *maybe* possible to do so (in a WebIDL compatible
browser at least,
Le 31/01/2013 19:12, François REMY a écrit :
In this instance, it's possible for you as a polyfill author to replace
Element.prototype.style by your own getter which returns your special
proxy objects which do what you expect on property set.
For the style case, it's *maybe* possible to do so
Do you have links to spec saying that the browser adds native event
handlers?
Here you are:
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html#events-in-decorators
The best that can be done here is contact the DOM Core people (that's
where events are now apparently), and
A search shows some old discussions of the topic mentioning that they
might be going in to future versions of the language, etc. But on the
other hand I've been told in response to this question before that
TC39 has a general policy against features that allow garbage
collection to be visible to
On Thu, Jan 31, 2013 at 1:48 PM, Kevin Gadd kevin.g...@gmail.com wrote:
A search shows some old discussions of the topic mentioning that they
might be going in to future versions of the language, etc. But on the
other hand I've been told in response to this question before that
TC39 has a
We have yet to find a solution that does not leak information between
two actors that are not supposed to be able to communicate. At this
point we have a lot of important work to do for ES6 and until someone
comes up with a solution to the security issues WeakRefs are
postponed.
I'm not an expert
Thank you for the detailed explanation of the information leak - I had
never seen an explanation of why GC visibility creates an issue.
Is there a page on the wiki somewhere that explains why information
leaks are such a huge concern in JavaScript? I've never been under the
impression that it is
On Thu, Jan 31, 2013 at 4:48 PM, Kevin Gadd kevin.g...@gmail.com wrote:
A search shows some old discussions of the topic mentioning that they
might be going in to future versions of the language, etc. But on the
other hand I've been told in response to this question before that
TC39 has a
Earlier today I discussed with Arv an approach for doing WeakRefs without
compromising security. (FWIW, I also posted this in my message near the end
of https://groups.google.com/forum/m/?fromgroups#!topic/nodejs/fV8MDpkBauw.
Thanks to Rick for the pointer.)
When a WeakRef from Realm A points at
Hi Tab, not quite. WeakMaps and WeakRefs address mostly disjoint use cases.
WeakRefs cannot be used to fully emulate the GC virtues of WeakMaps on the
one hand, and WeakMaps cannot be used to make an object accessible only
until it is not *otherwise* referenced. We separated the two because the
I wrote up the semantics of refutable destructuring as discussed in
yesterday's meeting:
http://wiki.ecmascript.org/doku.php?id=harmony:refutable_matching
In particular, this defines the meaning of the ?-operator in a fairly
straightforward manner.
The page also describes how the proposed
17 matches
Mail list logo
