- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Mon, 31 Aug 2009 22:19:32 -0700
- To: Travis Leithead <travil@microsoft.com>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>, Cameron McCormack <cam@mcc.id.au>, Tony Ross <tross@microsoft.com>, Adrian Bateman <adrianba@microsoft.com>
On Mon, Aug 31, 2009 at 10:07 PM, Travis Leithead<travil@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. I don't know what this means. 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. What for? [snip] > > 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. > Sounds like a bad idea and YSCISB.
Received on Tuesday, 1 September 2009 05:20:13 UTC