RE: Feedback on pointer events

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.

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

> 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 Friday, 21 February 2014 21:48:49 UTC