- From: Ojan Vafai <ojan@chromium.org>
- Date: Tue, 10 May 2011 08:55:22 -0700
- To: "Olli@pettay.fi" <Olli@pettay.fi>
- Cc: Jonas Sicking <jonas@sicking.cc>, 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>
- Message-ID: <BANLkTimw7BZqew-Adi2XU+LJUktc_dK-cQ@mail.gmail.com>
On Tue, May 10, 2011 at 4:14 AM, Olli Pettay <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> 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> 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. 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. -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 15:56:22 UTC