W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2011

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

From: Anne van Kesteren <annevk@opera.com>
Date: Thu, 13 Oct 2011 10:27:13 +0900
To: "Doug Schepers" <schepers@w3.org>, "Jacob Rossi" <Jacob.Rossi@microsoft.com>
Cc: public-webapps <public-webapps@w3.org>, "Adrian Bateman" <adrianba@microsoft.com>, "Arthur Barstow" <art.barstow@nokia.com>, "Chaals McCathieNevile" <chaals@opera.com>, "www-dom@w3.org" <www-dom@w3.org>
Message-ID: <op.v29nnnhj64w2qv@annevk-macbookpro.local>
On Thu, 13 Oct 2011 09:54:26 +0900, Jacob Rossi  
<Jacob.Rossi@microsoft.com> 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:


Meanwhile we have also made up the plan for exceptions -- everything is  
going to be DOMException -- and Gecko has already implemented the DOM4  

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

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


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

>>> [1] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/dc.html

Anne van Kesteren
Received on Thursday, 13 October 2011 01:28:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:59 UTC