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

Re: Conflicts between D3E and Web DOM Core

From: Glenn Maynard <glenn@zewt.org>
Date: Sun, 3 Apr 2011 12:09:03 -0400
Message-ID: <BANLkTik6d4dPVbMvJDBS5mWoLwv-1zVC1A@mail.gmail.com>
To: Ms2ger <ms2ger@gmail.com>
Cc: Jonas Sicking <jonas@sicking.cc>, 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 7: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]

Using an empty event type as a sentinel for an uninitialized event makes a
lot of sense, it's what DOM Events does with UNSPECIFIED_EVENT_TYPE_ERR, and
at least WebKit implements this.  I think it makes a lot more sense than
adding additional state.  (IIRC, Anne agreed when I last talked to him about
this, that it'd be better to reintroduce the no-empty-event-type restriction
than to add an initialized flag.  I suggest we return to this when he gets

Glenn Maynard
Received on Sunday, 3 April 2011 16:09:39 UTC

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