On Thu, 13 Oct 2011 09:54:26 +0900, Jacob Rossi
<[email protected]> wrote:
Talking with Doug this morning, it seems he didn't have a chance to
reply to your mail below since he's been pretty busy. I've provided
responses below inline, sorry for the delay!
Thanks for getting to them. These were the issues I could quickly find.
How did you make sure no other comments have been missed?
Replies to your responses below.
But e.g. I do not have a reply to these emails in my inbox as far as I
can tell:
http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0054.html
IE and Gecko match the spec. Opera and Webkit do not match the spec--but
that seems like a bug. I'm not sure why calling preventDefault() on one
dispatch of an event should cancel the default action of a second
dispatch of that event.
No, but after an event is dispatched you want event.defaultPrevented to
reflect the result and not have been reset.
Furthermore, applications don't have the ability to reset this flag
themselves. If implementations don't reset this flag for them, then
there's no way to separate the default actions between multiple
dispatches of the event (cancelling dispatch A always also cancels
dispatch B). However, if implementations do reset the flag then the
application can always elect to take into consideration the return value
of dispatch A when performing the default action of dispatch B.
As I suggested in the email we could make initEvent() reset these flags.
This is what DOM4 does.
http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0065.html
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.
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.
http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0067.html
I had difficulty testing in Opera (probably something silly I'm doing).
Opera does not have the optional argument for addEventListener prior to
Opera 12.
The spec indicates that calling preventDefault() should have no effect
on non-cancellable events (therefore defaultPrevented is still false).
The way this is phrased in the specification is highly confusing as
defaultPrevented does not mention the non-cancelable clause.
But at least Webkit, IE, and Gecko have interoperable implementations
that match the spec.
var e = document.createEvent("Event")
e.initEvent("test", false, false);
document.addEventListener("test", function(e) {
alert(e.defaultPrevented);
e.preventDefault();
alert(e.defaultPrevented);
});
document.dispatchEvent(e);
e = document.createEvent("Event")
e.initEvent("test", false, true);
document.dispatchEvent(e);
Yeah, so in Opera I get false, true, false, true, rather than false,
false, false, true.
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.
http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0122.html
Ah, yes, "may only be called" is a bit confusing. A clearer statement is
"must be called"--which is the intent. Otherwise, if you don't
initialize the event then you'll get an exception when you try to
dispatch it. I think this is a worthy grammatical clarification, so I've
updated the spec to be clearer.
This has no relation to my comment.
http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0131.html
Since this one's a bit longer, I'll reply separately on it.
Okay.
Furthermore given the normative changes that have occurred (e.g. to
event.type) another Last Call is needed where I wanted to note the
issues I
noted elsewhere in this thread, regarding not using Web IDL normatively
like all our other drafts if they are not addressed by then.
There has been a Last Call since the normative changes to Event Type:
Revision 1.189 made the changes to event.type
Revision 1.200 published the spec for the most recent Last Call
1.201 is not editorial either. And does not define the "callback this
value" I noticed.
According to the CVS log, all changes since that Last Call draft have
been editorial with the exception of Revision 1.204. However, that
change was more of a clarification which matches all implementations.
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".
[1] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/dc.html
--
Anne van Kesteren
http://annevankesteren.nl/
