W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2011

Re: Conflicts between D3E and Web DOM Core

From: Jonas Sicking <jonas@sicking.cc>
Date: Sun, 3 Apr 2011 23:43:04 -0700
Message-ID: <BANLkTinnSNbzCLc21D-eesVtb8qG0rHA=Q@mail.gmail.com>
To: Ms2ger <ms2ger@gmail.com>
Cc: Glenn Maynard <glenn@zewt.org>, Jacob Rossi <jrossi@microsoft.com>, Anne van Kesteren <annevk@opera.com>, Olli Pettay <Olli.Pettay@helsinki.fi>, "Olli@pettay.fi" <Olli@pettay.fi>, "www-dom@w3.org" <www-dom@w3.org>
On Sun, Apr 3, 2011 at 4:28 AM, Ms2ger <ms2ger@gmail.com> wrote:
> On 03/13/2011 06:58 PM, Glenn Maynard wrote:
>> On Sun, Mar 13, 2011 at 1:21 PM, Jonas Sicking<jonas@sicking.cc>  wrote:
>>>> Not all.  WebKit doesn't check whether initEvent was called; it just
>>>> checks whether event.type != "".  If it's to allow e.type == "", it
>>>> would need a new flag indicating whether initEvent was called.
>>> I don't see a reason to allow empty string as event name. I don't see
>>> a strong reason to forbid it either, but since we need some sort of
>>> state which indicates "event has been initied" then checking for empty
>>> type seems fine. So we could make initEvent throw if called with an
>>> empty type.
>> If initEvent is to stay required, I think this is best.  All else
>> equal, reducing hidden state is a clear win.
> I'm not sure about that. There doesn't seem to be a strong relation between
> and event having an empty type and it being uninitialized. I've changed DOM
> Core to add an "initialized" flag. [1]

It is if we define it that way, no? I guess I don't care much either
way as either solution is easy to implement and neither solution seems
harder to use in a sensible way.

However I don't see an advantage of having an initialized flag, and it
does seem like a good thing to be able to test if an event has been
initialized. Something that an empty type would expose.

/ Jonas
Received on Monday, 4 April 2011 06:44:10 UTC

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