Re: Conflicts between D3E and Web DOM Core

I agree that it seems very strange to allow uninitialized events to be
dispatched.

Can you think of any occasion when an author would do this without it
being a bug in their code? I.e. when someone does this intentionally
and expect a specific behavior?

It seems much more likely that if someone dispatches an uninitialized
event, they have a bug in their code. In that case it's generally to
their benefit if we throw an exception as it helps them find this
problem, rather than silently ignore it (firing an event which no one
listens to).

Hence it seems better to me to throw an exception.

/ Jonas

On Fri, Mar 11, 2011 at 9:54 AM, 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.
>
> What developer problem are we solving by making this change? What about the developer model is improving?
>
> It seems like a waste of time to be spec'ing things contrary to what is interoperable today (requiring initEvent) and yet has no real use case (when are synthetic events with an empty string name ever useful?). If we're going to ask implementations to change behavior from what they *all* do today, then there needs to be use case for the change.
>
> I'm fine with allowing empty string and null event names--this is somewhat interoperable today. I'm also fine with removing the restriction of whitespace in event names since no implementation has this restriction and I can imagine some use cases for it.
>
> 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.
>
>> -----Original Message-----
>> From: Glenn Maynard [mailto:glenn@zewt.org]
>> Sent: Thursday, March 10, 2011 7:45 AM
>> To: Anne van Kesteren
>> Cc: Olli Pettay; Olli@pettay.fi; www-dom@w3.org; Jacob Rossi
>> Subject: Re: Conflicts between D3E and Web DOM Core
>>
>> On Thu, Mar 10, 2011 at 10:10 AM, Anne van Kesteren <annevk@opera.com>
>> wrote:
>> > Because the initEvent() method in this case does not necessarily have
>> > to change anything. When invoked it could leave the object completely
>> > unchanged. Having it unset some special flag ("initEvent() invoked")
>> > would serve no purpose.
>>
>> FWIW, the requirement to call initEvent seemed directly tied in with the
>> requirement to have a non-empty event type.  DOM Events requires the latter,
>> so there's no additional restriction imposed by requiring initEvent--it's implied
>> anyway--and it doesn't introduce additional state, since checking for an empty
>> event type implicitly checks whether initEvent was called.
>>
>> Since DOM Core does allow the null string as an event type (consistent with
>> most browsers), it makes sense for the initEvent requirement can go away with
>> it.  At that point, it's just pointless additional state.
>>
>> --
>> Glenn Maynard
>
>> -----Original Message-----
>> From: Anne van Kesteren [mailto:annevk@opera.com]
>> Sent: Thursday, March 10, 2011 7:11 AM
>> To: Olli Pettay; Olli@pettay.fi
>> Cc: www-dom@w3.org; Jacob Rossi
>> Subject: Re: Conflicts between D3E and Web DOM Core
>>
>> On Thu, 10 Mar 2011 16:02:29 +0100, Olli Pettay <Olli.Pettay@helsinki.fi>
>> wrote:
>> > On 03/10/2011 10:01 AM, Anne van Kesteren wrote:
>> >> It is artificial because you can just invoke initEvent with the empty
>> >> string, false, and false, and the event object will be identical. So
>> >> you are essentially throwing for not invoking initEvent which is
>> >> rather silly.
>> >
>> > Why is that silly? Quite often when you have objects with some kind of
>> > init method, you want to "prevent" object usage before the init is
>> > called.
>>
>> Because the initEvent() method in this case does not necessarily have to change
>> anything. When invoked it could leave the object completely unchanged.
>> Having it unset some special flag ("initEvent() invoked") would serve no purpose.
>>
>>
>> --
>> Anne van Kesteren
>> http://annevankesteren.nl/
>
>

Received on Friday, 11 March 2011 21:46:44 UTC