On Thu, Sep 3, 2009 at 8:12 AM, Travis Leithead<tra...@microsoft.com> wrote: >>> 2- property inheritance (regarding 4.4.3 [interface prototype objects]) > >>Is this for the accessor (getter/setter) introduced in ECMAScript 5? > > Yes and no. Before ES5, browser venders still have ways of getting the > getter/setter pair (__defineGetter__/ __lookupGetter__), so the scenario is > still relevant. The meta-point is that it's more about being able to improve > the utility of extending or replacing the behavior of these properties.
If Web IDL is going to mention the accessor property in ECMAScript, I agree it would be very practical to have accessor properties on the corresponding interface prototype objects. Is there any plan to specify ES5 (or maybe existing ES getter/setter implementation) binding in Web IDL? Best, - Shiki > > -Travis > > -----Original Message----- > From: Shiki Okasaka [mailto:sh...@google.com] > Sent: Wednesday, September 02, 2009 7:10 AM > To: Travis Leithead > Cc: public-webapps@w3.org; Cameron McCormack; Tony Ross; Adrian Bateman > Subject: Re: [WebIDL] Feedback on the August 30 Editor's draft > > Hi Travis, > >> 1- Mixing-in mixins (regarding 4.2.8 [PrototypeRoot], and sundry other >> places in the spec) > > This looks to be a reasonable solution for the problem Andrew and > Cameron discussed about to me. > >> 2- property inheritance (regarding 4.4.3 [interface prototype objects]) > > Is this for the accessor (getter/setter) introduced in ECMAScript 5? > > Regards, > > - Shiki Okasaka > > > On Tue, Sep 1, 2009 at 2:07 PM, Travis Leithead<tra...@microsoft.com> wrote: >> Cameron et al., >> >> >> >> I have a couple pieces of feedback on this draft. >> >> >> >> Let me start by saying that this is a wonderful spec—much needed by the >> working group, and much appreciated by the IE team in relation to the >> additional clarity it provides for interpretation of other specs. >> >> >> >> Before I launch into the specific feedback, let me explain the principle >> behind my thinking: make the DOM binding for JavaScript as extensible as >> possible. I’d like to ensure that within reason, there is sufficient >> language binding to make the DOM as extensible and customizable as possible >> for web developers. For example, web developers that want to customize DOM >> behavior via one of its APIs should only have to do so at most once (or >> several times if the API is a mixin). Most of the design decisions for IE8’s >> DOM prototypes follow this principle. >> >> >> >> 1- Mixing-in mixins (regarding 4.2.8 [PrototypeRoot], and sundry other >> places in the spec) >> >> >> >> My first comment here is that this is overly complicated. I don’t quite >> follow why the mixin prototype object is defined to exist one level up from >> the object instance. This pretty much ensures that it’s impossible to >> override the behavior of a mixin property (operation) on any scope larger >> than instance-level. For example, a developer would like to customize the >> behavior of addEventListener by replacing the native property with his/her >> own behavior, which ultimately invokes the native addEventListener API via >> apply. To do this and comprehensively cover every case where a webpage could >> use addEventListener, the web developer must override every instance in the >> DOM. This is unmanageable for any practical application. Rather, if the >> mixin properties were defined to exist higher-up in the prototype chain, >> then much more “coverage” can be obtained by one replacement. Since the >> mixin may appear on other interfaces, the scenario is not a single-point of >> replacement, but in all likelihood, a manageable number. >> >> >> >> I propose simplifying the mixin design substantially. I would like to see >> TargetInterface implements MixinInterface; be interpreted as merging each >> property/operation that is defined on the MixinInterface interface with the >> properties/operations on the TargetInterface. Treat mixins as literally >> “mixing in” to their associated interface. This likely implies that no >> interface object nor associated interface prototype object need be created >> in the ECMAScript binding. Where the MixinInterface interface is implemented >> by AnotherInterface, it’s properties/operations are merged to that interface >> as well (creating a copy of the property/operations on AnotherInterface). >> >> >> >> I believe that design is simpler for web developers to understand, and also >> increases the utility of extending the functionality of typical mixins (like >> EventTarget). Today, no browser implementation that I’m aware of handles >> this consistently, and thus the risk to change the spec is very low. >> >> >> >> 2- property inheritance (regarding 4.4.3 [interface prototype objects]) >> >> >> >> Again, from the extensibility point of view, it’s concerning to me that >> properties as defined on an interface are not actually represented as >> properties on the corresponding interface prototype object! Rather, the spec >> as it is currently written, flattens all properties to the object instance >> (which appears to coincide with Safari’s behavior for properties). With the >> current approach, properties (i.e., those defined with ‘attribute’ in the >> WebIDL) cannot be overridden (or replaced) on anything other than object >> instances themselves. A key scenario for IE8 was the ability to customize or >> replace the functionality of innerHTML globally for all elements. Thus, we >> provided a property for innerHTML on the most general element type we had >> (Element—yes I know it’s not the correct prototype hierarchy—we’re working >> on that J). Web developers can customize and extend that property in one >> place for far-reaching impact with little effort. Naturally, properties on >> prototypes are meaningless when invoked directly (they need an instance >> object ‘this’ reference), which is why IE8 and Firefox require the use of >> call/apply to be used when direct-invoking these. Opera does not appear to >> define properties at any level in their prototype chain, yet respects the >> web author’s intent to override them (again, at any point in the hierarchy). >> I favor IE, FF, and Opera’s extensibility over Safari’s simplicity on this >> point. >> >> >> >> I propose defining properties (not just operations) on interface prototype >> objects. This proposal allows properties to be overridden/extended as easily >> as operations currently are. It also results in nice symmetry between the >> properties and operations defined on a WebIDL interface and the resulting >> interface prototype object. Finally, it more closely approximates the >> behavior available in three of the four major browser venders. >> >> >> >> I’m eager to discuss these issues with the working group. >> >> >> >> Again, thanks for this great specification and your time as an invited >> expert. >> >> >> >> -Travis >> >> > >
