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 10:02:53 -0800
Message-ID: <CADh5Ky1XL8Lfv-1EMu2hVRSGtGnovKTfxiNO06v=KE5LRV4THA@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 9:59 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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?

Nope. Other than name, it's exactly the same.

> / Jonas
Received on Wednesday, 29 February 2012 18:03:25 UTC

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