- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sun, 13 Mar 2011 10:21:31 -0700
- To: Glenn Maynard <glenn@zewt.org>
- Cc: 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 Fri, Mar 11, 2011 at 12:39 PM, Glenn Maynard <glenn@zewt.org> wrote: > On Fri, Mar 11, 2011 at 12:54 PM, Jacob Rossi <jrossi@microsoft.com> wrote: >> Actually, null string has nothing to do with it. Anne has spec'd the default to be empty string, not null. > > The null string and the empty string mean the same thing: "", not null. > >> But spending time defining behavior that conflicts all current implementations and has no use case just stalls the progression of DOM L3 Events and yields no real value add. > > 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. I'd also think it's fine to keep an internal flag which tracks if init has been called, either works for me. > Firefox seems buggy here. It neither dispatches the event nor throws > an exception when dispatchEvent is called without initEvent. It seems > to silently do nothing, which I think is wrong in any case. (I havn't > checked the source to see precisely what's happening.) Agreed, we should throw an exception. / Jonas
Received on Sunday, 13 March 2011 17:22:33 UTC