Re: Conflicts between D3E and Web DOM Core

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
back.)

-- 
Glenn Maynard