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 :)). 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
