RE: WebApps-ISSUE-178 (empty string and null event types): Implementations and DOM Core allow empty string and null event types [DOM3 Events]

> -----Original Message-----
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> Sent: Tuesday, May 10, 2011 1:57 PM
> To: Olli@pettay.fi
> Cc: Ojan Vafai; Simon Pieters; Jacob Rossi; www-dom@w3.org;
> annevk@opera.com
> Subject: Re: WebApps-ISSUE-178 (empty string and null event types):
> Implementations and DOM Core allow empty string and null event types
> [DOM3 Events]
> 
> >
> > I don't know why empty string needs to be handled specially.
> 
> The implementation needs to somehow know if the event has been initialized
> or not. In gecko we currently do that using an internal flag. It seems just as easy
> to do that by checking if the type is empty.
> 
> > But, what if initializing using null would throw and event.type would
> > be null before initializing?
> 
> That would work too. Though at least in gecko it would be no easier, and for the
> website it requires somewhat more code since you can't just do a boolean
> check. But at this point it's basically bikeshedding.
> 
> Is there a reason you think this solution is better?
> 
> > (Still not backwards compatible though)
> 
> Are you actually worried about backwards compat? I'm not, but I'd be
> interested to know if someone else is.
> 
> / Jonas

With all due respect, this sounds like feature creep to me. What's being asked here is for an API to detect whether an event object has been initialized or not. No such API exists today and I don't think that the event type is so special that it should be the way to indicate that. Being able to detect this is not a complaint I've ever heard about the event model. If you really want that, then you can detect it using try/catch and dispatchEvent() and the DISPATCH_REQUEST_ERR exception. 

I'd rather not try to change this now--DOM Events is over a decade in the making, let's ship it and let other specs (DOM Core?) extend upon it. My goal with this change was to remove a statement in the event model (throwing exceptions in this case) which no implementation supports nor has plans to support.

Thanks,

Jacob

Received on Wednesday, 11 May 2011 00:37:13 UTC