Expand mouse/click interactions

[patrickhlauke]

• introduce the concept of "compatibility" mouse events (to explain why UAs may choose to fire both touch and mouse/click)
• remove stray "the"
• expand note about when UAs typically don't fire mouse events+click - not just mutli-touch, but also any gestures that aren't a tap
• optimistically replace "click" with "activation/tap gesture", hoping lawers won't swoop down on it

[patrickhlauke]

the third bullet addresses #63

[RByers]

Looks good generally though we probably need to relax this slightly to handle long press or other contextmenu scenarios. Obviously we don't want to try to define gesture behavior exactly, just capture the most common developer expectations. For example, note that Chrome on desktop also implements a two-finger tap gesture as a contextmenu accelerator (that doesn't require waiting for the long press timer) but I don't think it's worth mentioning that explicitly.

[patrickhlauke]

would just saying "tap gesture" rather than "activation/tap gesture" be sufficiently vague to cover contextmenu as well (and lax enough for the two-finger tap accelerator gesture due to the "typically" at the start)?

[RByers]

Not in chromium's gesture terminology, no ("tap" and "long press" are entirely different gestures). You could say "single finger stationary gestures" to include them both. Or even just call them out explicitly, eg, "single finger activation gestures (like tap and long press)". I agree "typically" is enough to let us ignore the niche cases like "two finger tap".

[patrickhlauke]

single finger activation gestures (like tap and long press)

liking that...will make a change and force-push result

[patrickhlauke]

done

[patrickhlauke]

@rbyers right on both comments. fixed.

[RByers]

LGTM, thanks!