Re: SC's or techniques on Force and duration

On 10/12/2015 17:17, David MacDonald wrote:

> 1) Several of us tried touching events on our phones and moving away
> while pressing, and they did not fire using the "magic auto capture" you
> mention. Is this a special control behaviour that the author calls out
> voluntarily, or is it attached only to certain iOS/android touch events.

Sorry for the late reply. Right, the automatic capture here depends on 
the type of events you're listening to (and the type of element you're 
listening on).

First of, let's assume you're binding event listeners to the actual 
control (and not on body or html and using event delegation).

Now, say you have a <button>. If you put your finger on the button, and 
move the finger out of the button while still keeping it on the screen, 
the button will remain in the "pressed/down" state; additionally, the 
browser will keep firing "touchmove" events on the button, even when the 
finger isn't over the button anymore - this is the auto-capture bit. 
Compare this to what you'd expect from, say, mouse events, where events 
would not be fired anymore at the button after the mouse pointer left 
the boundary of the button. Lastly, if you then lift your finger outside 
of the button, it won't fire a "click" event  (as the browser assumes 
that all that movement of the finger means it's not really a "tap") - 
however, it will fire a "touchend" event. Long story short: if your code 
is listening for "touchend", you'd have to do additional work to then 
check if the touchend's coordinates fall back within the boundaries of 
the control.

The most generic demo I have that demonstrates these events firing even 
when your finger is outside of the button is probably 
http://patrickhlauke.github.io/touch/tests/event-listener_prevent-default-touchmove.html 
- put a finger on the button, then move it out of the button...note the 
touchmove events still fire, the button remains in a depressed state 
while your finger is outside of the button, and a final touchend is 
fired when the finger is lifted, regardless of whether it was inside or 
outside of the button's boundaries.

A slightly different, and probably less complex, example would be 
something like a native <input type="range"> - by default, iOS/Safari 
will allow you to do effectively the same as above: touch the slider, 
move your finger around the screen to change value, regardless of 
whether your finger remains over the input itself, and fire a "change" 
event at the end regardless of where your finger was when you lifted it.

> 2) The primary problem we are trying to address is allowing people to
> change their mind after they select something and before they remove
> their finger but we understand your desire to make it more generic.
> Perhaps we can keep our wording and add and OR statement.

Why not make the normative wording more generic (basically, just saying 
that actions are revocable), but then give non-normative/informative 
examples that are more specific? Otherwise I fear that the normative 
wording will be too closely tied to the current, very specific state of 
implementation in certain OS/UA combinations.

> How is this?
> *2.5.3 Single Taps and Long Presses Revocable:* Interface elements that
> require a single tap or a long press as input will only trigger the
> corresponding event when the finger is lifted inside that element unless
> their is a means of confirming before triggering the event, or the event
> can be reversed (Level A)

Also, looking more generally at this...would we really want to fail ALL 
instances of a control that doesn't implement something like "only 
activate if finger was lifted inside the element"/"action is revocable"? 
What if the outcome of triggering the control is completely trivial 
(i.e. not initiating a payment or something of import).

Further...would this sort of thing not also be a problem for a 
non-touchscreen user? For instance, a mouse user with dexterity 
problems? In fact, depending on the situation, wouldn't the auto-capture 
described above (being able to trigger a function even if the finger is 
NOT exactly over the control anymore) in fact be beneficial in certain 
situations, where a user may not have the most steady finger on a 
touchscreen?

P
-- 
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Tuesday, 15 December 2015 01:06:03 UTC