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

Re: non-normative examples for event sequences (and diagrams?)

From: Rick Byers <rbyers@google.com>
Date: Mon, 17 Feb 2014 11:32:59 -0500
Message-ID: <CAFUtAY8=HUgqv-nGwuGuBPrtonRZMi=vh6NwFa_Q0daU-9oPOQ@mail.gmail.com>
To: "Patrick H. Lauke" <redux@splintered.co.uk>
Cc: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Sorry for the delay - just got back from vacation.

I like these two examples since they're probably the two most
common/important cases, but I don't think we need to go overboard and
"sprinkle" such examples throughout the spec.  The mouse compat case is the
most complex and is a really a superset of the general case, so I think
just having these two examples in the mouse compat is sufficient (but I
don't have a strong feeling on this).

A couple issues with the specific examples:
 - pointermove/mousemove is possible before click (and I expect some UAs to
do this more than IE does today), so we should probably add that
 - maybe adopt a regex-style syntax to indicate what events _may_ occur
(enter/leave/over/out/capture), or may be repeated (move)?


On Mon, Feb 10, 2014 at 5:32 PM, Patrick H. Lauke <redux@splintered.co.uk>wrote:

> Just to get an early feel for this, one of my early proposals before
> joining the WG was to have some form of non-normative examples that clarify
> the *sequence* that events are fired (as that's what my own testing has
> focused on so far). Looking initially at 11.2 (compat mouse events for
> non-hover devices), the gist of what I'd like the spec to get across is
> this (which is, of course, contained in the algorithm steps, but may not be
> immediately graspable)
> "Example 9: sequence of events resulting from tapping an element on a
> touchscreen
> mousemove > pointerover > mouseover > mouseenter > pointerdown > mousedown
> > gotpointercapture > (focus, if the focus was previously on another
> element) > pointerup > mouseup > lostpointercapture > pointerout > mouseout
> > mouseleave > (focus, if no other element previously had focus) > click
> Example 10: sequence of events resulting from tapping an element on a
> touchscreen, when pointerdown is cancelled
> mousemove > pointerover > mouseover > mouseenter > pointerdown >
> gotpointercapture > (focus, if the focus was previously on another element)
> > pointerup > lostpointercapture > pointerout > (focus, if no other element
> previously had focus) > click"
> (I've included focus in these sequences, though that will depend in part
> on discussion around my proposed idea to include focus/blur information)
>  [1]
> Of course, these sorts of examples could also be extended further for
> mouse compat on hover-capable devices, and perhaps even outside for the
> mouse compat section, perhaps as a new part of 5.2?
> And although having the sequence written out as text, I also wonder if
> it's worth doing something a bit more...visually interesting (though of
> course with adequate accessible fallback). I quite like Apple's diagrams
> for event handling in iOS/Safari ... perhaps a good starting point. [2]
> So, my question I guess is: does the group think sprinkling these sorts of
> event sequence examples (and diagrams) not just in the mouse compat
> section, but also in 5.2, with a few variations, would be worthwhile? I can
> make a stab at the actual diagram creation.
> P
> [1] http://lists.w3.org/Archives/Public/public-pointer-events/
> 2014JanMar/0071.html
> [2] https://developer.apple.com/library/IOS/documentation/
> AppleApplications/Reference/SafariWebContent/
> HandlingEvents/HandlingEvents.html
> --
> Patrick H. Lauke
> ______________________________________________________________
> re·dux (adj.): brought back; returned. used postpositively
> [latin : re-, re- + dux, leader; see duke.]
> www.splintered.co.uk | www.photographia.co.uk
> http://redux.deviantart.com | http://flickr.com/photos/redux/
> ______________________________________________________________
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> ______________________________________________________________
Received on Monday, 17 February 2014 16:33:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:48:09 UTC