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

Re: [DOM4] EventTarget as first class citizen

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Thu, 22 Mar 2012 16:18:51 +0200
Message-ID: <4F6B34CB.80002@helsinki.fi>
To: Jonas Sicking <jonas@sicking.cc>
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 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;
}




-Olli
Received on Thursday, 22 March 2012 14:20:35 GMT

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