- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 1 Sep 2009 02:31:57 -0300
- To: Garrett Smith <dhtmlkitchen@gmail.com>
- Cc: Travis Leithead <travil@microsoft.com>, "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 Tue, Sep 1, 2009 at 2:19 AM, Garrett Smith<dhtmlkitchen@gmail.com> wrote: > 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? One thing that comes up every so often is a desire to know which event handlers a page has added to a node. The use cases so far haven't been compelling enough that we've added support for this to the spec, however a page could do something very similar by overriding addEventListener and storing the added eventhandlers separately using the UserData APIs. > [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. What is YSCISB? / Jonas
Received on Tuesday, 1 September 2009 05:32:57 UTC