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

On Tue, May 10, 2011 at 12:46 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
> On 05/10/2011 10:05 PM, Jonas Sicking wrote:
>>
>> On Tue, May 10, 2011 at 10:27 AM, Olli Pettay<Olli.Pettay@helsinki.fi>
>>  wrote:
>>>
>>> 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 i'm proposing is that we change that so that attempting to
>> initialize to empty string throws an error. I strongly doubt that this
>> will break pages.
>
> 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

Received on Tuesday, 10 May 2011 20:58:23 UTC