- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Tue, 10 May 2011 22:46:44 +0300
- 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