Re: [DOM3Events] Oustanding issues (was: [DOM3Events] CR)

On Thu, 13 Oct 2011 11:32:34 +0900, Jacob Rossi  
<Jacob.Rossi@microsoft.com> wrote:
> Your welcome, I appreciate your tolerance! I made a sweep in good faith  
> through the list archives and was unable to find other unanswered issues.

It is somewhat sad comments are not being tracked. I just went through the  
archives again
http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0107.html does not  
seem to have a response.


>> No, but after an event is dispatched you want event.defaultPrevented to  
>> reflect the result and not have been reset.
>
> The result is reflected in the return value from dispatchEvent().   
> defaultPrevented is for use by event listeners; the return value of  
> dispatchEvent is for use by event dispatchers.

But that is not what is implemented.


>> As I suggested in the email we could make initEvent() reset these flags.
>> This is what DOM4 does
>
> I see no need to require authors to call initEvent with the same  
> parameters simply to reset these flags (and to make at least 3  
> implementations change).

Implementations will have to change either way, see above. With what I am  
saying you can also catch get hold of the final value for non-synthetic  
events. That does not work if you reset it prematurely.

The other option is resetting the "canceled flag" at the start of a  
synthetic dispatch invocation.


>>> Whether D3E needs EventException was covered in the discussion for
>>> ISSUE-179 (http://www.w3.org/2008/webapps/track/issues/179).
>>
>> Yes, and you have not replied to my latest comments on that issue:
>>
>> http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0047.html
>>
>> Meanwhile we have also made up the plan for exceptions -- everything is  
>> going to be DOMException -- and Gecko has already implemented the DOM4
>> behavior.
>
> I've noted your response to the group's resolution on this issue in the  
> disposition of comments. I'll reply to the thread to ensure that's clear  
> to anyone else reading the archives.

This is not a sufficient reply to the new information I just brought  
forward.


>>>> http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0066.html
>>>
>>> The efforts DOM4 makes here are great extensions to DOM L3 Events.
>>
>> These are not extensions. This is basic functionality that needs to be  
>> defined.
>
> We were fine without such definitions in DOM L2 Events. Even if DOM3  
> Events defined this, then I would consider that an extension to DOM L2  
> Events. I see no difference if this is left for DOM4 to define.

We were not fine at all. It was one of the many bugs in DOM Level 2  
Events. If you want to knowingly perpetuate this bug you have to spell  
that out in the draft so it is at least clear it is not defined.


>>>>    http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0068.html
>>>
>>> I could see a future spec allow this given a good set of scenarios.
>>> DOM3 I believe DOM4 does this. But I don't see this as a requirement
>>
>> It's about how the feature is implemented today. The definition in DOM  
>> Level 3
>> Events does not match existing implementations and as Boris indicates in
>> http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0071.html this
>> might be a compatibility hazard.
>
> I'm sorry, what I wrote above wasn't meant to be in response to this  
> issue. I pasted my response under the wrong thread. My response below  
> ("Ah, yes 'may only......") was in reference to this issue.
> This sentence in the spec wasn't ever intended to prohibit calling  
> initEvent() after dispatch. Rather, it was intended to say that you must  
> initialize it before dispatch. Calling it again after dispatch is  
> allowed, and as you note it is implemented that way across browsers.

The specification currently reads "This method has no effect if called  
after the event has been dispatched." So I am not sure what you are  
talking about.


> Now, in regards to:  
> http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0122.html
>
> This is a non-normative table that describes common target types for  
> events defined in DOM3 Events.  From above the table:
>
> "Refer to the specification defining the language used in order to find  
> those restrictions or to find event types that are not defined in this  
> document. The following table provides a non-normative summary of the  
> event types defined in this specification."
>
> Because it is non-normative, it does not forbid dispatching load events  
> at XMLHTTPRequest, for example.

Non-normative is not some license to write down nonsense. Please correct  
the text.


>> 1.201 is not editorial either. And does not define the "callback this  
>> value" I noticed.
>
> A fragment sentence (editorial) caused the commenter (Rob Brackett) to  
> not understand the intended behavior of the spec (which is interoperably  
> implemented).  I removed this ambiguity. The commenter agreed we weren't  
> "changing the specified behavior" and was satisfied with the change:
> http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0045.html
> http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0058.html

Defining that you can pass a Function object is not editorial.


>> You still need to use Web IDL though. And update exception handling in  
>> line with recent events. If you are not going to use Web IDL and the  
>> rest of the WG is somehow okay with that you need to define things such  
>> as "callback".
>
> I find it odd that we'd stall the progression of this spec so it can be  
> revised to take a normative dependency on a spec which published its  
> current Working Draft two weeks ago. As a compromise, we added a  
> non-normative appendix that provides WebIDL definitions based on the  
> current state of WebIDL.
>
> Your disagreement with the resolution is now noted in the disposition of  
> comments.

I would like to make that a formal objection. I do not think the WebApps  
WG should publish standards that are not using Web IDL.


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

Received on Thursday, 13 October 2011 03:34:36 UTC