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

On 2/17/14 11:32 AM, ext Rick Byers wrote:
> 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)?

At the risk of `stating the obvious`, besides adding this type of 
information directly to the spec, there are of course other ways to 
document examples and/or best practices such as using the group's wiki. 
Section 2.1 of the group's charter is explicit about this "Primer or 
Best Practice documents to support web developers when designing 
applications. " < 
http://www.w3.org/2012/pointerevents/charter/#ig-other-deliverables>.

(If we want to work on some type of Primer/BP doc, we could use Hg or GH 
to facilitate broader participation.)

-AB


>
> Rick
>
>
> On Mon, Feb 10, 2014 at 5:32 PM, Patrick H. Lauke 
> <redux@splintered.co.uk <mailto: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 <http://www.splintered.co.uk> |
>     www.photographia.co.uk <http://www.photographia.co.uk>
>     http://redux.deviantart.com | http://flickr.com/photos/redux/
>     ______________________________________________________________
>     twitter: @patrick_h_lauke | skype: patrick_h_lauke
>     ______________________________________________________________
>
>

Received on Tuesday, 18 February 2014 15:24:34 UTC