W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2012

Re: [DOM4] EventTarget as first class citizen

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 22 Mar 2012 15:30:26 -0700
Message-ID: <CA+c2ei8PFiS2LzVybb5ix+Hozb+aCG0Rtf0Rs1h673KXAj6BLA@mail.gmail.com>
To: olli@pettay.fi
Cc: Erik Arvidsson <arv@chromium.org>, Anne van Kesteren <annevk@opera.com>, Boris Zbarsky <bzbarsky@mit.edu>, Dimitri Glazkov <dglazkov@chromium.org>, www-dom@w3.org, Alex Russell <slightlyoff@google.com>
On Thu, Mar 22, 2012 at 7:18 AM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
>
> On 03/06/2012 03:52 AM, Jonas Sicking wrote:
>>
>> On Mon, Mar 5, 2012 at 10:26 AM, Erik Arvidsson <arv@chromium.org> wrote:
>>>
>>> On Sat, Mar 3, 2012 at 15:40, Jonas Sicking <jonas@sicking.cc> wrote:
>>>>
>>>> Note, I don't think that anyone is suggesting to add
>>>> .parentNode/.eventTargetParent to the EventTarget interface. But
>>>> rather just to objects instantiated through the constructor described
>>>> in this thread.
>>>
>>>
>>> FWIW, some JS libraries have custom EventTarget implementations and
>>> they use parentEventTarget as a way to determine how to do the
>>> propagation.
>>>
>>> One problem with only allowing the parent in the constructor is that
>>> it becomes read only. Most use cases for custom EventTargets that
>>> involve propagation also requires being able to reparent that objects.
>>
>>
>> Cool, so if people are doing this already, with modifyable
>> .parentEventTarget, then I think we should do that. Allowing it to be
>> modified is really only a matter of checking for cycles the the
>> property is assigned to.
>>
>> / Jonas
>>
>
>
> I wouldn't actually add anything to EventTarget, since nodes etc are event
> targets and we don't want to have
> somenode.parentEventTarget.
>
> Could we have
> [Constuctor]
> interface EventReceiver : EventTarget {
>  attribute EventTarget parent;
> }

This would be ok with me. It does mean that pages would have to
instantiate 'EventReceiver' rather than 'EventTarget' which I think is
unfortunate. But it does avoid having to place a getter/setter
directly on the object returned from the EventTarget ctor.

To be clear, what I was thinking was to add something like the equivalent of:

function EventTarget(parent) {
  var parent;
  Object.defineProperty(this, "parentEventTarget", {
    get: function() { return parent; },
    set: function(newparent) {
      ... check for cycles ...;
      parent = newparent;
  });
  if (parent) {
    this.parentEventTarget = parent;
  }

  return this;
}

Obviously the implementation would be different, but the above
describes the API that the page would see.

/ Jonas
Received on Thursday, 22 March 2012 22:31:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:09 GMT