- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 10 May 2011 12:05:06 -0700
- To: Olli@pettay.fi
- 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 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