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

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

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Tue, 10 May 2011 22:46:44 +0300
Message-ID: <4DC99624.8050606@helsinki.fi>
To: Jonas Sicking <jonas@sicking.cc>
CC: Ojan Vafai <ojan@chromium.org>, Simon Pieters <simonp@opera.com>, Jacob Rossi <Jacob.Rossi@microsoft.com>, "www-dom@w3.org" <www-dom@w3.org>, "annevk@opera.com" <annevk@opera.com>
On 05/10/2011 10:05 PM, Jonas Sicking wrote:
> On Tue, May 10, 2011 at 10:27 AM, Olli Pettay<Olli.Pettay@helsinki.fi>  wrote:
>> On 05/10/2011 06:55 PM, Ojan Vafai wrote:
>>> On Tue, May 10, 2011 at 4:14 AM, Olli Pettay<Olli.Pettay@helsinki.fi
>>> <mailto: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
>>>         <mailto: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
>>>                 <mailto: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.
>> That is not the case. You can initialize event to empty string in
>> all engines without init*() method throwing. And after that you
>> certainly have initialized the event, and could assume that dispatching
>> it works.
> What i'm proposing is that we change that so that attempting to
> initialize to empty string throws an error. I strongly doubt that this
> will break pages.

I don't know why empty string needs to be handled specially.
But, what if initializing using null would throw and
event.type would be null before initializing?
(Still not backwards compatible though)

>>> 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.
>> There isn't such API atm either.
>> Event.type doesn't tell anything about event being initialized.
> If we made initing to an empty string throw an error it would. I don't
> think this is particularly important though. But I do think that there
> is a distinct possibility use cases will arrive in the future forcing
> us to make such a mechanism available.
> / Jonas
Received on Tuesday, 10 May 2011 19:47:57 UTC

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