W3C home > Mailing lists > Public > public-pointer-events@w3.org > January to March 2014

Re: Feedback on pointer events

From: Anne van Kesteren <annevk@annevk.nl>
Date: Mon, 17 Mar 2014 15:48:06 +0000
Message-ID: <CADnb78gEcnZTPMxdGAJNBLjTLiJBYZDmZhmqwojwr8UvBF+9VA@mail.gmail.com>
To: Jacob Rossi <Jacob.Rossi@microsoft.com>
Cc: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
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.

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

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

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

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.

Received on Monday, 17 March 2014 15:48:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:26 UTC