- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Tue, 18 Feb 2014 10:23:32 -0500
- To: Rick Byers <rbyers@google.com>, "Patrick H. Lauke" <redux@splintered.co.uk>
- CC: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
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