On Sep 26, 2009, at 3:58 PM, Cameron McCormack wrote:
Cameron McCormack:
Indeed, much of the custom [[Get]] etc. functionality can be
turned into
ES5 meta-object stuff. A pertinent question is then: should we
change
Web IDL to specify an ES5 binding (and not ES3) at this point, given
that specs depending on it want to advance along the Rec track?
Mark S. Miller:
Since ES5 will be officially done well ahead of HTML5, I don't see
why
not. But I do not know what your "Rec track" constraints imply.
For example, Selectors API is at Last Call and will soon be in
Candidate
Recommendation. I don’t think it can progress further than that until
its dependencies move forward.
Selectors can't progress to PR/REC until Web IDL is in at least CR
state (only one difference in maturity level is allowed for
dependencies). I think Web IDL can enter CR with ES5 as is, but it
will be considered final as soon as it is published, which is likely
to be before Web IDL is ready for Last Call. ECMA process does not
have any states between the equivalent of W3C Working Draft and W3C
REC (as far as I know). So I don't think this would create any
problems for Selectors advancing, other than the time to do the rewrite.
On the substantive issue: I do think it would be good to convert Web
IDL from ES3 formalisms to ES5 formalisms. While Oliver is right that
ES5 has not yet been proven by interoperable implementations, and that
some of its methods as defined have a hard time with host objects, I
believe that the basic designs of ES5 property descriptors and ES5
getters/setters are sound.
Regards,
Maciej
