W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2012

Re: Web IDL attributes and delegation

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 12 Sep 2012 18:14:47 +0100
Message-ID: <5050C307.2020607@mit.edu>
To: "public-script-coord@w3.org" <public-script-coord@w3.org>
On 9/12/12 4:38 PM, Colin Snover wrote:
> As a JS author, it is important to me to be able to have a way to
> augment DOM event objects and/or override certain properties (which may
> be defined as readonly) in a time- and memory-efficient manner.

In a browser that implements WebIDL as written, this can be accomplished 
by simply defining properties on the event object, right?

> Right now, most script libraries end up doing a shallow copy of properties
> from the native event object to a surrogate and then fix up the standard
> event methods (stopPropagation, etc.) to point back to the native
> object, which is quite inefficient, and can be especially bad for
> performance when dealing with high-volume events (touchmove, mousemove,
> etc.). Delegation via e.g. Object.create should be a more reasonable way
> to accomplish this

I'm trying to understand why a separate object is needed at all.  Is 
this just working around the fact that some implementations put IDL 
attributes directly on the object, not on the prototype?

> I strongly believe that browser vendors should be making every effort to make
> host/platform objects indistinguishable from native JavaScript objects
> as much as possible

Let's stop and do a thought experiment.  Say you implement the innerHTML 
getter that lives on HTMLElement.prototype in JavaScript.  Assume that 
your DOM is in fact implemented as native JavaScript objects (so your 
DOM nodes are native objects), but complies with the DOM specification.

Now say a web page does:

   var elem = document.createElement("span");
   elem.innerHTML = "<i>Something</i>"
   var obj = Object.create(elem);
   Object.defineProperty(obj, "firstChild", { value: elem; });

What should happen and why?

> My first thought for an alternative proposal, were one to be
> entertained, would be to fix the |this| value of platform object
> getter/setters to the platform object itself

Which particular platform object?  Note that the getters live on the 
prototype, not on the platform object itself.

> whilst still allowing
> read-only properties to be safely redefined on the delegate.

Again, this can already be done with Object.defineProperty in UAs that 
actually implement WebIDL.

Received on Wednesday, 12 September 2012 17:15:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:07 UTC