W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: [WebIDL] Feedback on the August 30 Editor's draft

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 1 Sep 2009 02:31:57 -0300
Message-ID: <63df84f0908312231t70832bdve0b78e51eb8cc1b@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT