RE: Feedback on pointer events

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.

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

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