Proxying Native Objects: Use case
bruant.d at gmail.com
Thu Jan 31 08:46:03 PST 2013
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:
> element.style.myCustomProperty = true;
> // set the my-custom-property custom CSS property
How is this not future-hostile?
Do you have a link to where people are discussing this?
>> 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.
> Thanks, that's a good idea. But you didn't comment on the possibility to simply turn any object into a proxy using
Turning any object into a proxy is a no-go, because it means that things
are aren't observed suddenly have to be observed and that anyone can
insert arbitrary code in the middle of any operation on any object. It's
pretty bad both for security and probably for performance too.
I think having dispatchEvent accepting proxies is the easiest thing to
do in your case.
If creating proxies for exotic objects become a real thing, maybe each
exotic type can define its own reduced version of proxies like:
The power proxiedElementHandler could be arbitrarily reduced by the spec
of createProxiedElement. It could allow creating reduced "proxies" that
can be inserted in the DOM without providing full abusive power than
have the bad consequences for selector matching. It's possible in
theory. In practice, I don't believe it'll happen :-s
More information about the es-discuss