RE: Feedback on pointer events

On Mon, Mar 17, 2014 at 8:48 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>
> On Fri, Feb 21, 2014 at 9:48 PM, Jacob Rossi <Jacob.Rossi@microsoft.com> wrote:
> > Hi Ann,
>
> Hi Jaco,
>
>
> >> 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.
>
> That seems better. You still need to define how all the members are initialized.

Ah yes, that is missing. I've assigned an action to myself to do this. 
https://www.w3.org/2012/pointerevents/track/actions/101


> >> 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.
>
> You've only done this for a couple of events, while all the events
> need to be dispatched as queued tasks from some kind of operating
> system UI loop.

The only "async" events in the spec are gotpointercapture and lostpointercapture.  There's active discussion on how to more properly define this (Bug 24971).
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24971


Are you proposing that the synchronous events also need further definition?  Looking through other specs (e.g. XHR Level 2), I don't see such definitions beyond using the term "fire an event" as defined in DOM.

> >> 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.
>
> Yeah that seems slightly better.
>
>
> What I'm missing still is that some of these events have actions
> associated with them if the event is not canceled. So you fire the
> event, you check if it's canceled flag is set, and then you run a
> certain set of steps. That is not concretely defined at the moment.

There are two reasons a pointer event is cancellable:

First, cancelling pointerdown will prevent the firing of certain mouse events for that pointer. This is specified in Section 11.1 step 4.

Second, cancelling a pointer event will also cancel the corresponding compatibility mouse event (if there is one). Hence, the remaining cancellable pointer events are so by nature of their corresponding mouse events being cancellable.  The specific default action & steps for those mouse events is out of scope for this group. But I think this is solved by modifying steps 4 & 5 in section 11.1 and steps 5 &6 in section 11.2 to set the cancelled flag of the mouse event being fired to true.

>
> Nit: "boundaries of all of its children", you want descendants there.

Indeed.

>
> I'm a bit concerned too by the language of y is fired after x if z.
> Can we not make that a concrete set of steps around firing x? It's not
> clear e.g. if those are fired on the same task or on different tasks
> at the moment. Or in other words, the modeling is somewhat sketchy.
>

If you can propose spec text that might make this clearer, I'm happy to take a look.

Received on Tuesday, 15 April 2014 05:53:37 UTC