- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Thu, 22 Mar 2012 16:18:51 +0200
- 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 UTC