On Thu, 13 Oct 2011 11:32:34 +0900, Jacob Rossi
<[email protected]> 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/
