- From: Charles Pritchard <chuck@jumis.com>
- Date: Mon, 5 Mar 2012 10:58:26 -0800
- To: Erik Arvidsson <arv@chromium.org>
- Cc: Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@opera.com>, Boris Zbarsky <bzbarsky@mit.edu>, Dimitri Glazkov <dglazkov@chromium.org>, "www-dom@w3.org" <www-dom@w3.org>, Alex Russell <slightlyoff@google.com>
On 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. > >> We can either do that by inserting another interface which just >> contains this new property. Or by adding the property on the instances >> themselves. I don't have a strong opinion either way, but it would >> seem nice if we can still call the constructor 'EventTarget'. > > Another option is to allow manual propagation. It still requires that > the EventTarget is extended so maybe it is just simple to have a new > property? > > -- > erik Something along these lines came up for mouse events generated within new Canvas APIs. I don't believe there's a need, but it was brought up by Benjamin and by Hixie on separate occasions. > http://wiki.whatwg.org/wiki/Canvas#Regions http://lists.w3.org/Archives/Public/public-canvas-api/2012JanMar/0005.html -Charles
Received on Monday, 5 March 2012 18:58:56 UTC