WebIDL attribute reflection

David Bruant bruant.d at gmail.com
Sun Dec 30 10:58:18 PST 2012

Le 30/12/2012 17:48, Boris Zbarsky a écrit :
> On 12/29/12 10:49 PM, Boris Zbarsky wrote:
>> One other note.
> And one last note, promise.
In my opinion, we get too rarely this kind of feedback from implementors 
on es-discuss. I'm personally learning a lot.

> The point is that SpiderMonkey is working on changing its internal 
> model to more closely match the spec.  And I agree with that approach: 
> for any somewhat complicated spec, using an internal model that 
> doesn't match the spec model is just a recipe for pain and 
> non-conformance.  You can try to fake things with enough epicycles, 
> but like any epicycle setup as soon as you can make more accurate 
> measurements you have to add more epicycles.  That means that things 
> meant as "specification devices" become de-facto conformance 
> requirements as specs grow hidden dependencies on those exact 
> algorithms being used.
True. As far as proxies are concerned, I think it's actually a good 
thing. I'll explain that in a separate post soon.

> As a simple example, any time someone adds a DOM getter that calls 
> into page script (assuming there is no such thing already, which I 
> woudln't be on!) calls to [[GetOwnProperty]] become script-detectable 
> if DOM properties are value properties (because you have to call the 
> getter to fill in the descriptor), so if at that point you aren't 
> implementing exactly the spec's algorithms you're detectably 
> non-conformant.
> And even if you don't call into page script, there are various getters 
> that have detectable side-effects already (e.g. any of the CSSOM 
> getters have side-effects on starting times of CSS transitions).
I'm not enough familiar with CSSOM getters and CSS transitions, sorry; 
is it a spec requirement or an observation shared for all current 
As I said in the previous post, some things like innerHTML ought to stay 
accessors. The criterion could be whether getting or setting has an 
effect observable outside of the object the property is on. So if the 
CSSOM spec says some getters have a side-effect on CSS transitions 
starting time, let these be accessors.

> Thus if you use a specification device in terms of a proxy that 
> implements getOwnPropertyDescriptor only, suddenly sets of offsetWidth 
> (a readonly property, note) start having side-effects which they don't 
> have right now, and implementations that don't have those side-effects 
> become non-conformant.  Again, just as an example of how a 
> "specification device" can turn into an unintended conformance 
> requirement.
That'd be a spec bug, but one that is easy to make when unfamiliar with 
proxies I agree.
The solution here would be to define the set trap as first performing a 
check on whether the property is a readonly one.
Spec bugs can be avoided if a lot of people read the spec and if 
interoperability tests are developed. I'm not that worried about 
unintended conformance requirement.

I feel that for the vast majority of cases in the web platform, WebIDL 
is the only place that'll need to use proxies (exception for live 
objects and WindowProxy and probably a handful of other weirdnesses). If 
the WebIDL part is done right once, everything will follow fine.
In the upcoming weeks, I'll take a stab at drafting what WebIDL would 
look like if defining attributes as own data properties using proxies. 
We'll see how it goes.

> So I'm very much against using a specification device that doesn't 
> match the intended implementation, which is what you seem to be 
> proposing.  In my experience, that leads to implementations which 
> don't actually match the spec in all sorts of edge cases.  If we're 
> lucky, they match each other and all that has to happen is the spec 
> has to be rewritten somehow.  But more commonly they don't match each 
> other either, and you end up with interoperability problems, which 
> means your standardization effort just failed...
I haven't been in the web platform for long enough, but I feel now more 
people read the specs, catch bugs, discuss, write test cases than 
before. I wonder if standardization efforts can "just fail" as much as 
they did in the past. I feel spec errors are caught much much earlier 
than what I hear from how things were 5+ years ago.
To people who've been there for much longer than me, is it a shared feeling?


More information about the es-discuss mailing list