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: Wed, 29 Feb 2012 18:59:16 +0100
Message-ID: <CA+c2ei82Ur0qpqaCUrqGzZC=fM6isWWTkF_ifrn0PqmVQNz=MQ@mail.gmail.com>
To: Dimitri Glazkov <dglazkov@chromium.org>
Cc: Anne van Kesteren <annevk@opera.com>, Marcos Caceres <w3c@marcosc.com>, www-dom@w3.org
On Wed, Feb 29, 2012 at 5:41 PM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
> 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.

Not sure I understand the proposal. Are you saying we should introduce
a .parentNode property on the new EventTarget object? Would it be
different in anything other than name from what I proposed above?

/ Jonas
Received on Wednesday, 29 February 2012 18:00:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:18 UTC