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

>> 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:29:31 UTC