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

> -----Original Message-----
> From: Anne van Kesteren [mailto:annevk@opera.com]
> Sent: Wednesday, October 12, 2011 6:27 PM
> To: Doug Schepers; Jacob Rossi
> Cc: public-webapps; Adrian Bateman; Arthur Barstow; Chaals McCathieNevile;
> www-dom@w3.org
> Subject: Re: [DOM3Events] Oustanding issues (was: [DOM3Events] CR)
> 
> 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?

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.

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

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.

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

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). I can't think of a valid scenario not solved by DOM3Events' definition. The return value of dispatchEvent() will indicate the result of the flag per dispatch. Then author can decide if he or she wants to do some logical combination of those return values if he or she wants preventDefault() to persist across dispatches. I believe the most common case, however, is that each dispatch will have a default action and you'll want a fresh set of flags for that--DOM3 Events has optimized for this scenario (but doesn't prohibit building an application that does otherwise).

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

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.

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

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

I didn't find it confusing. But I don't want to be confusing to others, so I don't mind clarifying it. I'll do this along with the editorial changes suggested by Ms2ger.

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

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

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.

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

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




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

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.

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

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

Received on Thursday, 13 October 2011 02:33:17 UTC