W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2011

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 10 May 2011 12:05:06 -0700
Message-ID: <BANLkTin=z97gzJ6v-shv6139YFjCeLYogQ@mail.gmail.com>
To: Olli@pettay.fi
Cc: Ojan Vafai <ojan@chromium.org>, Simon Pieters <simonp@opera.com>, Jacob Rossi <Jacob.Rossi@microsoft.com>, "www-dom@w3.org" <www-dom@w3.org>, "annevk@opera.com" <annevk@opera.com>
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.

>> 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.

If we made initing to an empty string throw an error it would. I don't
think this is particularly important though. But I do think that there
is a distinct possibility use cases will arrive in the future forcing
us to make such a mechanism available.

/ Jonas
Received on Tuesday, 10 May 2011 19:29:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:07 GMT