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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
