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

>> 2- property inheritance (regarding 4.4.3 [interface prototype objects])

>Is this for the accessor (getter/setter) introduced in ECMAScript 5?

Yes and no. Before ES5, browser venders still have ways of getting the getter/setter pair (__defineGetter__/ __lookupGetter__), so the scenario is still relevant. The meta-point is that it's more about being able to improve the utility of extending or replacing the behavior of these properties.

-Travis

-----Original Message-----
From: Shiki Okasaka [mailto:shiki@google.com]
Sent: Wednesday, September 02, 2009 7:10 AM
To: Travis Leithead
Cc: public-webapps@w3.org; Cameron McCormack; Tony Ross; Adrian Bateman
Subject: Re: [WebIDL] Feedback on the August 30 Editor's draft

Hi Travis,

> 1- Mixing-in mixins (regarding 4.2.8 [PrototypeRoot], and sundry other
> places in the spec)

This looks to be a reasonable solution for the problem Andrew and
Cameron discussed about to me.

> 2- property inheritance (regarding 4.4.3 [interface prototype objects])

Is this for the accessor (getter/setter) introduced in ECMAScript 5?

Regards,

 - Shiki Okasaka


On Tue, Sep 1, 2009 at 2: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. 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 J). 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
>
>

Received on Wednesday, 2 September 2009 23:13:30 UTC