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

On 05/10/2011 06:55 PM, Ojan Vafai wrote:
> On Tue, May 10, 2011 at 4:14 AM, Olli Pettay <Olli.Pettay@helsinki.fi
> <mailto:Olli.Pettay@helsinki.fi>> wrote:
>
>     On 05/10/2011 12:57 PM, Jonas Sicking wrote:
>
>         On Tue, May 10, 2011 at 2:19 AM, Simon Pieters<simonp@opera.com
>         <mailto:simonp@opera.com>>  wrote:
>
>             On Tue, 10 May 2011 09:53:36 +0200, Jonas
>             Sicking<jonas@sicking.cc>  wrote:
>
>                 On Monday, May 9, 2011, Jacob
>                 Rossi<Jacob.Rossi@microsoft.com
>                 <mailto:Jacob.Rossi@microsoft.com>>  wrote:
>
>
>                     Hi folks,
>
>                     In recognition that implementations support null and
>                     empty string event
>                     types and that DOM Core allows this, we accepted the
>                     change to D3E to remove
>                     this restriction. I have removed the spec text in
>                     the exceptions section
>                     which required
>                       an exception be thrown in these cases.
>
>
>                 Hmm. I only vaguely remember the tail end of this
>                 discussion, but
>                 wasn't the conclusion that it was better to let empty
>                 string signify
>                 an uninitialized event?
>
>     There certainly wasn't such conclusion.
>     Gecko now throws an exception if non-initialized event is dispatched,
>     but it doesn't matter what the event type string contain.
>
>
> As best I can tell, that thread ended with a number of people voicing in
> favor of letting the empty string signify an uninitialized event.
>
>         Thus making empty string a not allowed name.
>
>
>                 The alternative is to force the event to hold some
>                 hidden state which
>                 indicates if it has been initialized or not. This is
>                 worse both from
>                 an implementation complexity aspect, as well as removes
>                 the ability
>                 for pages to check if an event has been initialized (I
>                 don't have any
>                 use cases for the latter, but it's a nice free bonus)
>
>
>             Some argued for that but DOM Core was then changed to have a
>             flag -
>             http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#initialized-flag
>
>
>         Why? What was the advantage with that approach?
>
>     The advantage is to keep event.type a separate thing which
>     doesn't affect event dispatch.
>
>
> Why is this a good thing? Using the empty string event type reduces
> hidden state and gives a way for web developers to check whether an
> event is uninitialized.
That is not the case. You can initialize event to empty string in
all engines without init*() method throwing. And after that you
certainly have initialized the event, and could assume that dispatching
it works.



> What is the advantage of keeping it separate?
>
>       I'd rather not head
>
>         down a path that'll make us add extra API
>
>     What extra API? The flag is an internal thing.
>
>
> I believe he meant exposing something to the web to see if an event is
> initialized.

There isn't such API atm either.
Event.type doesn't tell anything about event being initialized.

-Olli



>
>     -Olli
>
>         just to check the
>         initialized flag if someone comes up with a use case a couple of
>         years
>         down the road.
>
>         / Jonas
>
>

Received on Tuesday, 10 May 2011 17:28:33 UTC