RE: Feedback on pointer events

On Mon, Feb 24, 2014 at 9:56 PM, Rick Byers <rbyers@google.com> wrote:
>
> Thanks for the updates Jacob!  A couple issues inline...
>
> On Feb 21, 2014 4:48 PM, "Jacob Rossi" <Jacob.Rossi@microsoft.com> wrote:
> >
> > Hi Ann,
> >
> > Thanks for the detailed review. I agree with these improvements (modulo point 7, which we have a branch of this thread discussing) and have committed a fairly large update to the latest editor's draft [1] that should address these. Since it's a larger change, I'll walk through what I've done:
> >
> > > Hi,
> > >
> > > bz and I had a brief look at this specification earlier today and found a number of issues.
> > >
> > > 1. PointerEvent constructor is not defined. You probably just want to reference http://dom.spec.whatwg.org/

> >
> > At the end of Section 5.1, I've added a reference to your definition in DOM4.
> >
> > > 2. The only place that maps event names (types) to their corresponding interface is non-normative.
> >
> > Yes, indeed. I've added Section 5.2.1 that details the steps to fire a pointer event using the PointerEvent interface.  Then, in each of the places throughout the spec (mostly sections 5.2.3 - 5.2.12) where an even is fired, these steps are now referenced.
> >
> > > 3. Instead of dispatch you want to talk about firing events, see http://dom.spec.whatwg.org/#concept-event-fire for the general idea and http://xhr.spec.whatwg.org/#concept-event-fire-progress for how to do it on an Event subclass. You will have define how to set all the properties of the class as well.
> > Yes, this will also help clear up the "dispatch" meaning confusion pointed out by Patrick.  The new section on firing pointer events (5.2.1) now hooks into the process for firing/dispatch an event as you've defined in DOM4. In addition, I've replaced all instances of "dispatch" with "fire a pointer event named", except in the cases where the spec literally means to describe specifically the act of dispatching.
> >
> > > 4. You cannot talk about "asynchronously" dispatch this day and age.
> > > You'll have to define how your standard interacts with the event loop:
> > > http://www.whatwg.org/specs/web-apps/current-work/#event-loop

> >
> > Yes, that would be clearer for sure. I've integrated this with the event loop / task queue definitions from HTML5.
> >
> > > 5. Why is pointercancel cancelable?
> > It shouldn't be (we discussed this on our last WG call too).  Fixed, along with pointerenter/leave which have no defined cancelable actions either.
>
> Looks like you forgot to remove it from the new list in 5.2.1.

Ah, looks like a typo:  s/pointercancel/pointerup

I just pushed a fix for this.

> >
> > > 6. A bunch of events are cancelable. In order to define that properly you need to define something like a) Fire an event /x/; b) If /x/'s canceled flag is unset, run Y. Otherwise it is unclear what needs to happen.
> > This has also been included in the new section on firing a pointer event.
>
> Where?  I see this only for pointerdown.

It seems move, up, over, and out are still only listed non-normatively in the events table. These events are cancellable because their mouse event equivalents are cancellable (as defined in DOM3 Events). So, when a pointer is primary, cancelling a pointerdown should act as though the mousedown compatibility event was also cancelled.  Unfortunately, that spec isn't as explicit as it could be about the specific actions that are cancelled as a result (and implementations may vary in some case I bet).  But I don't see that as a problem Pointer Events should solve. 

Perhaps we can add to the end of 5.2.1:

"While executing the steps to fire the event (defined in DOM4), if a user agent support compatibility mouse events then the following steps should be run when a browser is to about to dispatch the pointer event:
1. If the input device supports hover, run the steps defined in Section 11.1
2. If the input device does not support hover, run the steps defined in Section 11.2"

Then, in sections 11.1 and 11.2, modify the steps that say to fire a mousedown/move/up/over/out event (the cancelable ones) to say "fire a mouse____ event with the cancelled flag initialized to the value of the cancelled flag resulting from the dispatch of the pointer event."

I'm open to suggestions for cleaner solutions. This is a bit tricky since we need to plug into multiple stages in the event firing algorithm.

> >
> > > 7. Why is maxTouchPoints not exposed on Screen?
> > This was addressed by Olli and I concur with his explanation [2]. Windows/IE, for example, support "indirect" touch devices that aren't necessarily associated with a screen.
> >
> > > 8. It would be much better if pointer capture became part of the overall dispatching model rather than a separate set of steps you have to merge in your head with what came before (and hope it still makes sense!).
> > Yeah, my original intent here was to have a whole section explaining pointer capture end to end, since it is a new concept. But I do see how that's hard to merge with the rest. So, you'll now see I've integrated this into the new section on firing pointer events, which should make this clearer.
> >
> > [1] https://dvcs.w3.org/hg/pointerevents/rev/1667331a62ff

> > [2] http://lists.w3.org/Archives/Public/public-pointer-events/2014JanMar/0081.html

Received on Tuesday, 25 February 2014 07:18:17 UTC