Re: Hover click with pointer events

On 16/06/2015 17:42, Rick Byers wrote:
> Button #0 is defined
> <http://www.w3.org/Submission/pointer-events/#button-states> as the 'pen
> contact' button, right?  It seems we have at least the following two
> choices:
>
> 1) Allow firing pointerup / pointerdown for pen outside of contact
> scenarios.  Eg. redefine button #2 to be just "barrel button" (instead
> of "pen contact with barrel button pressed).  This seems like it's
> probably bad for web compatibility and might make it harder for
> developers to do common things.

The "barrel button" is supposed to be equivalent to right-mouse/context 
menu. As such, when pressed in the air, it should just fire pointermove 
(as per spec) and click, rather than pointerup / pointerdown.

Same for any "left-mouse button" type buttons (Surface Pen lacks this - 
it only has barrel, erase, and the non-remappable Microsoft OneNote one 
at the top 
https://www.microsoft.com/surface/en-gb/support/touch-mouse-and-search/surface-pen 
  - but Wacom Bamboo does have it - left-click, right-click, erase 
http://us.wacom.com/~/media/WTC/Files/Manuals/Legacy/Bamboo%20Pen%20Bamboo%20Touch%20Bamboo%20Fun.pdf/ 
(p 43)). Fire pointermove and click.

> 2) Allow the 'buttons' state to change while hovering.  Apps that wanted
> to support "hover click" would need to watch pointermove for changes in
> buttons.  This is a little more awkward, but it's a pretty special case
> anyway that I doubt most developers would ever want to support.  So I'm
> OK with it being more difficult.

For left-mouse button and right-mouse button / activation and barrel, 
and possibly also for erase, would devs also be able to just listen for 
click as usual? (not tested, but: does click in theory also have the 
same button/buttons that you'd get from listening to pointermove instead?)

P
-- 
Patrick H. Lauke
--
Senior Accessibility consultant
The Paciello Group (UK office)
http://www.paciellogroup.com

Received on Tuesday, 16 June 2015 17:23:34 UTC