Re: Re: Conflicts between D3E and Web DOM Core

On Thu, 10 Mar 2011 04:30:17 +0100, Jacob Rossi <jrossi@microsoft.com>  
wrote:
>> 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.

It is artificial because you can just invoke initEvent with the empty  
string, false, and false, and the event object will be identical. So you  
are essentially throwing for not invoking initEvent which is rather silly.


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

It is not just about use cases. It is also about well defined behavior.


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

I removed the optional arguments for initEvent() already if that is what  
you mean. I agree that was not that useful.


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

Agreed (well minus what I said above if you consider that a change to  
initEvent() rather than dispatchEvent()).


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

Reality does all kinds of crazy things unfortunately. Also on the web.  
That is why we attempt to define APIs in detail so that it becomes  
impossible for authors to rely on implementations details. That is why we  
now have a defined way of parsing HTML, why parsing CSS is defined  
including error handling, etc. Not everything has an author facing use  
case.

What is written in the HTML Design Principles document also applies here:  
http://www.w3.org/TR/html-design-principles/#interoperability


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Thursday, 10 March 2011 08:13:08 UTC