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: Jacob Rossi <Jacob.Rossi@microsoft.com>
Date: Tue, 10 May 2011 17:07:58 +0000
To: "Olli@pettay.fi" <Olli@pettay.fi>, Jonas Sicking <jonas@sicking.cc>
CC: Simon Pieters <simonp@opera.com>, "www-dom@w3.org" <www-dom@w3.org>, "annevk@opera.com" <annevk@opera.com>
Message-ID: <D0BC8E77E79D9846B61A2432D1BA4EAE0293B4D0@TK5EX14MBXC116.redmond.corp.microsoft.com>
Additionally, the spec text I removed stated functionality which *no* implementation supported (throwing exceptions for empty string or null types). 

-----Original Message-----
From: Olli Pettay [mailto:Olli.Pettay@helsinki.fi] 
Sent: Tuesday, May 10, 2011 4:14 AM
To: Jonas Sicking
Cc: Simon Pieters; Jacob Rossi; www-dom@w3.org; annevk@opera.com
Subject: Re: WebApps-ISSUE-178 (empty string and null event types): Implementations and DOM Core allow empty string and null event types [DOM3 Events]

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.

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

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


> just to check the
> initialized flag if someone comes up with a use case a couple of years 
> down the road.
> / Jonas
Received on Tuesday, 10 May 2011 17:08:28 UTC

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