RE: Feedback on pointer events

Thanks for the updates Jacob!  A couple issues inline...

On Feb 21, 2014 4:48 PM, "Jacob Rossi" <> 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
> At the end of Section 5.1, I've added a reference to your definition in
> > 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 for the general idea and 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:
> >
> 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

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
> [1]
> [2]

Received on Tuesday, 25 February 2014 05:57:12 UTC