- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sun, 3 Apr 2011 23:43:04 -0700
- To: Ms2ger <ms2ger@gmail.com>
- Cc: Glenn Maynard <glenn@zewt.org>, Jacob Rossi <jrossi@microsoft.com>, Anne van Kesteren <annevk@opera.com>, Olli Pettay <Olli.Pettay@helsinki.fi>, "Olli@pettay.fi" <Olli@pettay.fi>, "www-dom@w3.org" <www-dom@w3.org>
On Sun, Apr 3, 2011 at 4:28 AM, Ms2ger <ms2ger@gmail.com> wrote: > On 03/13/2011 06:58 PM, Glenn Maynard wrote: >> >> On Sun, Mar 13, 2011 at 1:21 PM, Jonas Sicking<jonas@sicking.cc> wrote: >>>> >>>> Not all. WebKit doesn't check whether initEvent was called; it just >>>> checks whether event.type != "". If it's to allow e.type == "", it >>>> would need a new flag indicating whether initEvent was called. >>> >>> I don't see a reason to allow empty string as event name. I don't see >>> a strong reason to forbid it either, but since we need some sort of >>> state which indicates "event has been initied" then checking for empty >>> type seems fine. So we could make initEvent throw if called with an >>> empty type. >> >> If initEvent is to stay required, I think this is best. All else >> equal, reducing hidden state is a clear win. > > I'm not sure about that. There doesn't seem to be a strong relation between > and event having an empty type and it being uninitialized. I've changed DOM > Core to add an "initialized" flag. [1] It is if we define it that way, no? I guess I don't care much either way as either solution is easy to implement and neither solution seems harder to use in a sensible way. However I don't see an advantage of having an initialized flag, and it does seem like a good thing to be able to test if an event has been initialized. Something that an empty type would expose. / Jonas
Received on Monday, 4 April 2011 06:44:10 UTC