RE: Re: Conflicts between D3E and Web DOM Core

> From: 
> Date: Fri, 04 Mar 2011 09:22:13 +0100
>  To: "www-dom@w3.org" <www-dom@w3.org>, "Jacob Rossi"
> <jrossi@microsoft.com>
> Message-ID: <op.vrs77bql64w2qv@anne-van-kesterens-macbook-pro.local>
> 
> Thanks for your feedback and doing this analysis!
> 
> On Thu, 03 Mar 2011 23:06:33 +0100, Jacob Rossi <jrossi@microsoft.com>
> wrote:
> > I've identified some potential conflicts between Web DOM Core and DOM
> > L3
> > Events:
> >
> >  1. WDC allows the dispatch of an event without having initialized its
> > event object (e=document.creatEvent("Event"); window.dispatchEvent(e);).
> > No major browser supports this today and there are not any valid use
> > cases for this behavior (that I can think of), so why make
> > implementations change?
> 
> Why should we have the artificial restriction? What exactly does
> initEvent() do that is required here? 

initEvent() populates the event object with the necessary properties to make it useful. An event without a type is just a bad programming practice that we shouldn't be encouraging. You use the term "artificial" yet it's not artificial: *all* browsers have this restriction today and it's what the spec says. Changing it to be otherwise requires me to ask, "what's the use case?"  Unless there's a valid use case for events without a name, then there's no reason to change.

> I wanted the specification to both reflect
> implementations and make some sense. E.g. in Gecko getting Event.type before
> invoking initEvent() throws an exception. But there is no real reason why that
> should be the case. Nor is that defined by DOM Level 3 Events, so changes will
> be needed either way.

How does this "reflect implementations" since no browser allows this? I agree Gecko shouldn't be throwing an exception. But what's the use case to get the type before initialization? I don't see the point in changing a spec to mandate something that has no implementation nor use case.

As I've said before, I agree that we should look into a better initialization experience than what exists today. But your proposal doesn't solve the issue--it alleviates some pain by making the simplest cases (a basic Event object with the type set to something) easy but doesn't solve the places where the init methods are the most cumbersome, like initMouseEvent() with 15 required input arguments.

We should leave the init methods as they are today and propose a separate and complete model for initializing event objects (such as constructors or your property bag init method idea). Another spec could even take up the task of defining such an initialization model since it won't conflict with D3E.

> 
> > 2. cancels and bubbles are now optional arguments for initEvent() in
> > WDC.  How does this merge with the other init___Event( ) methods which
> > are have cancels and bubbles in the middle of their methods? I think
> > there's some support for improving how the init methods behave, but
> > this doesn't really solve that problem. I'd rather see D3E keep these
> > are required and then Web DOM Core consider taking the task of event
> > object constructors. [1]
> 
> Reverted for now:
> https://bitbucket.org/ms2ger/dom-core/changeset/c8ce92f749e3
> 
> (I will put forward a proposal for easier event creation in the firing
> thread.)
> 
> 
> > 3. Event names can be empty strings but not null in WDC [2]. Why
> > exclude null, it's not any more nonsensical than "". IE9, Chrome, and
> > Opera all allow null as a name.
> 
> As pointed out by Glenn this is not true. Note also that DOM Level 3 Events does
> seem to have restrictions here. No whitespace characters allowed?
> dispatchEvent() seems to say a INVALID_CHARACTER_ERR exception is thrown
> for an incorrect Event.type...

I was incorrect in saying WDC prohibits null as an event name. I misread the sentence " If listener is null terminate these steps" as "If type is null terminate these steps."

Glenn correctly pointed out that Chrome changes null to "null" (and actually, so does IE9 and Opera). This is because that's how ECMAScript converts null to strings. What wasn't mentioned, however, is that IE9/Chrome/Opera all do this for addEventListener(null,foo) as well (it's the same as addEventListener("null",foo)). So it's interoperable with the exception of one browser.

Even still.....is this really all that important? Again I ask, "what's the use case?"
It feels like we're defining behavior that will never be used in reality.

Received on Thursday, 10 March 2011 03:30:54 UTC