- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 10 May 2011 02:57:22 -0700
- To: Simon Pieters <simonp@opera.com>
- Cc: 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 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? 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? I'd rather not head down a path that'll make us add extra API 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 09:58:19 UTC