Proxying Native Objects: Use case

David Bruant bruant.d at gmail.com
Thu Jan 31 09:50:08 PST 2013


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:
>>>
>>> element.style.myCustomProperty = true;
>>> // set the my-custom-property custom CSS property
>> How is this not future-hostile?
> Custom properties are guarenteed to start with a prefix (EWCG sports 'my' and Tab sports 'var' but in concept this is identical) so that the getter only get in the way if the property name starts by that prefix. That prefix being secured for author additions only, it's impossible that any conflict will happen in the future.
Ok, good to know. Thanks :-)

>> Do you have a link to where people are discussing this?
> Feel free to comment on www-style, but if you want Tab's editor draft, it's here:
>
> http://www.w3.org/TR/css-variables/#cssstyledeclaration-interface
> The most natural way seems to be to first, set up a getter behavior on the interface that deals with variable properties, and second, set up a vars map that exposes the variable properties that aren't set to their initial value.
>
> FWIW, I support both additions, given the author prefix.
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 dispatchEvent/addEventListener case, it's possible for you to 
override these methods (and maybe the Proxy constructor?) to accept 
proxies the way you want them to.

I think web browsers implementing proxies are/will be sufficiently 
WebIDL compliant to make such a polyfill not that hard to write.

David


More information about the es-discuss mailing list