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

On Tuesday, May 10, 2011, Jacob Rossi <Jacob.Rossi@microsoft.com> wrote:
>> -----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.

I can live with the current behavior. However so far it seems like
most people think that having hidden state is a bad thing, and no one
has provided any benefits to the currently specced behaviour.

So I just don't understand te reason why not to change?

However I definitely am not going to ask that the spec be held up over
this issue (worst come to worst we can always change it later if it
becomes important).

/ Jonas

Received on Wednesday, 11 May 2011 01:59:35 UTC