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

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

Rick


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