Re: Feedback on pointer events

Thanks Jacob, hope somewhat restored.

On Tue, Apr 15, 2014 at 6:52 PM, Jacob Rossi <Jacob.Rossi@microsoft.com> wrote:
> 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.

Agreed. I have asked this to be fixed for UI Events here
http://lists.w3.org/Archives/Public/www-dom/2014JanMar/0064.html and
have so far not received a response. DOM Level 3 Events is probably a
lost cause.


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

This seems better. What actually happens I suppose is that the
platform queues a task and the event is dispatched from there.


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

Yes, it clarifies e.g. whether it gets priority over other tasks if
the user agent has task source prioritization.


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

Yes! That is what we should define. "As a task is queued by the
platform on the UI task source for x, do y."


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

Yes, this is going in the right direction, except that I think these
events are all dispatched as part of the same task in implementations
today. The difference would be that other unrelated tasks (e.g.
timers) could execute between these tasks, but not if you dispatch
them all from one. That difference is observable and important to nail
down.

(Unfortunately it's a bit late here, can probably no longer reply tonight :/)


-- 
http://annevankesteren.nl/

Received on Tuesday, 15 April 2014 19:02:25 UTC