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 clarify, both for Object.create and proxy, your "does not work"
means "cannot be put in the DOM tree". The output object still behaves
as expected from an ECMAScript point of view.
It remain possible to do wrappedNode1.appendChild(wrappedNode2) by
unwrapping both wrappedNode under the hood.
I've however a compelling use case that may make some of us rethink the
situation.
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.
As a side note, I hope this is not a new API, because such getters are
particularly bad taste. I remember it generated some issues with
HTMLCollection. Maybe something about making it inherit from Array and
static analysis on websites.
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
For this kind of API, I largely prefer the CustomEvent approach where
the (unique!) "detail" field is by-spec expected to be a "go crazy" type
of field. The "detail" attribute also doesn't collide with any existing
field; in the MapEvent case, a getter could shadow an inherited property.
In case of no-proxy-for-native-objects, I've no way to do it properly because
implementing 'getter' requires me to use a Proxy but having a functional event will force
me to use a natively-branded element (like document.createEvent("CustomEvent"))
and changes its prototype chain to match my needs.
The conclusion I was personally at was that every single API will have
to decide how it behaves with proxies. We've seen previously that
proxies in appendChild were a no-go because browsers traverse the DOM
tree for selector matching and putting proxies in the tree would reveal
how selector matching is performed, thus ruining hope of making it parallel.
However, off top of my head, I don't see a main restriction to call
.dispatch with a proxied event as argument. I'm not enough expert of
this topic; people who are in how the APIs are used and implemented will
better tell whether it's appropriate to accept a proxy.
I'll post to public-script-coord to talk about that.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
