RE: Feedback on pointer events


On Tue, Apr 15, 2014 at 3:33 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>
> On Tue, Apr 15, 2014 at 6:53 AM, Jacob Rossi <Jacob.Rossi@microsoft.com> wrote:
> > Are you proposing that the synchronous events also need further definition?
>
> What do you mean synchronous? User input is not synchronous.

Sorry, you're right that "synchronous" is a nebulous term when discussing user input.  Let's class this differently. Gotpointercapture and lostpointercapture fire as the result of method calls and other defined processes (e.g. setPointerCapture()). The remaining pointer events fire as the result of user actions.User input specs up until this point (e.g. Touch Events recommendation, DOM L2/L3 Events, UI Events, etc.) haven't really defined how user input events relate to the task queues defined for other events and processes, which is less than ideal. 

So I think my question to you is: do you think it is sufficient to have the spec say what it does now for those user action triggered events? Example:
" A user agent MUST fire a pointer event named pointermove when a pointer changes coordinates." [1]

Or, do you think this ought to be defined as queuing a task to fire the event? Example:
"When a pointer changes coordinates, a user agent must queue a task to fire a pointer event named pointermove."

Both, I believe, result in the same observable platform behavior, but the latter makes it clearer to how they relate with other tasks defined in specs.  The reality is that browsers don't really queue a separate task after observing a change in user input. Rather, the platform is providing input messages to the browser that the browser then synchronously (e.g. on the same stack) fires an event. Those input messages, however, can essentially be thought of as the queued task caused by the user input. So if you think the latter definition is better, I'd be happy to make that change. But I wasn't positive this was the feedback you were giving when you said " all the events need to be dispatched as queued tasks from some kind of operating system UI loop."


> > 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.
>
> If you declare fundamental bits out of scope, how do you expect
> interoperable implementations?
>
>
> >> Nit: "boundaries of all of its children", you want descendants there.
> >
> > Indeed.
>
> But you did not fix it?
Sorry, meant to assign myself an action for this since it was past working hours for me when I replied. I've now updated the spec:
https://dvcs.w3.org/hg/pointerevents/rev/e3a3f3019cf7 

> >> 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.
>
> Usually when a reviewer points out a problem, it's up to the editor to
> be grateful (optional, I suppose, but it helps in getting more
> reviews) and fix it.

I see how that came across as ungrateful--that wasn't my intent. I think your review of the spec has generated substantial improvements to the Pointer Events spec, which is in turn raising the bar (in a good way) compared to prior input specifications. 

What I meant by this was that your comment is general and one specific example in the spec might help me better understand the problem you see. Here's what I think is an example of the problem you're talking about here:
" After firing the pointercancel event, a user agent MUST also fire a pointer event named pointerout followed by firing a pointer event named pointerleave." [2]

If I understand the problem correctly, then the spec text might be changed to:
"When any of the following occurs [insert the 2 bullet points of user input scenarios that cause a pointercancel], a user agent must:
    1. Queue a task to fire a pointer event named pointercancel
    2. Queue a task to fire a pointer event named pointerout
    3. Queue a task to fire a pointer event named pointerleave"

Is this an example of the problem you're pointing out and do you agree with that type of solution? If so, then I think understand what needs to change in the spec to address it. Otherwise, a specific example of spec text would help me better understand.

-Jacob

[1] https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#the-pointermove-event

[2] https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#the-pointercancel-event

Received on Tuesday, 15 April 2014 17:52:59 UTC