WebIDL attribute reflection

David Bruant bruant.d at gmail.com
Mon Dec 31 02:24:19 PST 2012

Le 31/12/2012 07:19, Boris Zbarsky a écrit :
> On 12/30/12 1:20 PM, Claude Pache wrote:
>> FWIW, I used the fact that, in IE 8 & 9, innerHTML is conveniently a 
>> configurable accessor found at Element.prototype (in IE8) or 
>> HTMLElement.prototype (in IE9), for correcting a quirk of its setter, 
>> by extracting it and replacing it with a corrected version.
> Indeed, this is one of the major reasons properties are accessors in 
> WebIDL.  It allows libraries to polyfill functionality as it's added 
> in specs (e.g. if the set of things that can be assigned to a property 
> changes, that may be possible to polyfill by hooking the setter).
>> I don't know if and how it would be possible if it was an own 
>> property on each instance
> It wouldn't be possible, in the proposals I've seen so far in this thread.
Polyfillability is an interesting criteria. Is 
Object.getOwnPropertyDescriptor polyfillability important? Would a good 
[[Get]]+[[Set]] polyfill be enough? By that I mean that as long as the 
[[Get]]+[[Set]] behavior is good, maybe polyfilling a property by an 
accessor is good enough?
I tend to consider data or accessor property as an implementation 
detail. It's important to specify it in WebIDL for interoperability, but 
authors should be worried of making the [[Get]]/[[Set]] protocol work 
and use the rest of the tooling (low-level property descriptor stuff) to 
make this work.

If necessary, WebIDL is free to add custom property descriptor 
attribute. It could look like:

     Object.defineProperty(webIDLObject, 'bla', {value: 25, webIDLType: 

And it would create an own property of type long (so subject to all 
relevant WebIDL logic). I would prefer that innerHTML stay a 
getter/setter, but it could be possible to describe it as an own 
property and send out its logic through a property descriptor attribute. 
Very heavy-weight, but technically possible. I prefer the getter/setter 


More information about the es-discuss mailing list