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

Re: [DOM4] EventTarget as first class citizen

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Wed, 29 Feb 2012 08:41:58 -0800
Message-ID: <CADh5Ky1mAto=b0FbZx_YANbDan4p3s-FhAdT-Dr=a1VPwozJhQ@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Anne van Kesteren <annevk@opera.com>, Marcos Caceres <w3c@marcosc.com>, www-dom@w3.org
On Wed, Feb 29, 2012 at 8:25 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Wed, Feb 29, 2012 at 3:24 PM, Anne van Kesteren <annevk@opera.com> wrote:
>> On Mon, 27 Feb 2012 15:18:55 +0100, Marcos Caceres <w3c@marcosc.com> wrote:
>>>
>>> On Thursday, February 23, 2012 at 3:18 PM, Jonas Sicking wrote:
>>>>
>>>> I think the way we should do this is to enable instantiating
>>>> EventTarget objects using an EventTarget ctor. This won't give you a
>>>> neato extension syntax, but I think we'll have to rely on ES.next for
>>>> that. Before ecma-script has a better solution you can always
>>>> monkeypatch the object.
>>>>
>>>> So something like:
>>>> a = new EventTarget();
>>>> b = new EventTarget(a); // a is the parent in the target chain
>>>>
>>>> should be doable. I don't know if we need a way to modify the parent
>>>> chain after construction. It's somewhat complex to allow this while
>>>> still preventing cycles from being created.
>>>
>>> It would be great to see something like the above.
>>
>> Unless someone explains how that graph model applies to the tree model we
>> have now and what the processing model around it will, I'm not sure this
>> will go anywhere.
>
> Sorry, I guess I left out that critical part.
>
> The simplest solution would be that for something like
>
> b = new EventTarget(a);
>
> say that "a" must be an object created using the EventTarget
> constructor. As long as we don't have syntax for modifying the "event
> target parent" there would be no way of constructing arbitrary graphs.
> Only trees would be constructable. That's what I meant with the part
> about not being able to modify the parent in the original email.
>
> A more complex solution would also allow modifying the target-chain
> parent. For something like
> b.eventTargetParent = a;

What if we just make it traverse using parentNode accessor? This way,
the current event dispatch can be formulated consistently for DOM and
non-DOM objects.

> we would have to walk up a's parent chain and check if b is in the
> chain. If it is we'd have to throw an exception. We'd also have to
> require that a is constructed using the EventTarget constructor.
>
> Either of these methods will result in only trees and not arbitrary graphs.
>
> / Jonas
>
Received on Wednesday, 29 February 2012 16:42:32 GMT

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