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

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

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Mon, 31 Aug 2009 22:19:32 -0700
Message-ID: <c9e12660908312219n62ab72e9h7efc0c2434c016d@mail.gmail.com>
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 GMT

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