Re: WebApps-ISSUE-178 (empty string and null event types): Implementations and DOM Core allow empty string and null event types [DOM3 Events]

On Tue, May 10, 2011 at 4:14 AM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:

> On 05/10/2011 12:57 PM, Jonas Sicking wrote:
>
>> On Tue, May 10, 2011 at 2:19 AM, Simon Pieters<simonp@opera.com>  wrote:
>>
>>> On Tue, 10 May 2011 09:53:36 +0200, Jonas Sicking<jonas@sicking.cc>
>>>  wrote:
>>>
>>>  On Monday, May 9, 2011, Jacob Rossi<Jacob.Rossi@microsoft.com>  wrote:
>>>>
>>>>>
>>>>> Hi folks,
>>>>>
>>>>> In recognition that implementations support null and empty string event
>>>>> types and that DOM Core allows this, we accepted the change to D3E to
>>>>> remove
>>>>> this restriction. I have removed the spec text in the exceptions
>>>>> section
>>>>> which required
>>>>>  an exception be thrown in these cases.
>>>>>
>>>>
>>>> Hmm. I only vaguely remember the tail end of this discussion, but
>>>> wasn't the conclusion that it was better to let empty string signify
>>>> an uninitialized event?
>>>>
>>> There certainly wasn't such conclusion.
> Gecko now throws an exception if non-initialized event is dispatched,
> but it doesn't matter what the event type string contain.


As best I can tell, that thread ended with a number of people voicing in
favor of letting the empty string signify an uninitialized event.

Thus making empty string a not allowed name.
>>
>>>
>>>> The alternative is to force the event to hold some hidden state which
>>>> indicates if it has been initialized or not. This is worse both from
>>>> an implementation complexity aspect, as well as removes the ability
>>>> for pages to check if an event has been initialized (I don't have any
>>>> use cases for the latter, but it's a nice free bonus)
>>>>
>>>
>>> Some argued for that but DOM Core was then changed to have a flag -
>>> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#initialized-flag
>>>
>>
>> Why? What was the advantage with that approach?
>>
> The advantage is to keep event.type a separate thing which
> doesn't affect event dispatch.


Why is this a good thing? Using the empty string event type reduces hidden
state and gives a way for web developers to check whether an event is
uninitialized. What is the advantage of keeping it separate?


>  I'd rather not head
>
>> down a path that'll make us add extra API
>>
> What extra API? The flag is an internal thing.
>

I believe he meant exposing something to the web to see if an event is
initialized.

-Olli
>
>  just to check the
>> initialized flag if someone comes up with a use case a couple of years
>> down the road.
>>
>> / Jonas
>
>