[pointerevents] Stylus eraser: should it be a new pointerType instead of a button state?

mustaqahmed has just created a new issue for 
https://github.com/w3c/pointerevents:

== Stylus eraser: should it be a new pointerType instead of a button 
state? ==
I couldn't locate the motivation in the spec for treating "eraser" as 
a button state instead of a pointerType. Have we ever considered 
adding a new pointerType="eraser"?

Below are my thoughts about why pointerType="eraser" seems to be a 
better idea. To ease the discussion, I will use "eraser mode" to mean 
the physical orientation of a pen that is flipped to become an eraser,
 and "pencil mode" to mean the pen's normal orientation. (If the pen 
doesn't allow the flipped orientation but has a "eraser" button 
instead, my points still hold although a bit weakly.)

Consider a pen that is switched from "pencil" to "eraser" mode while 
_hovering_. Even though [our recent spec 
change](https://github.com/w3c/pointerevents/pull/96) supports 
hovering pen buttons, this state of the pen seems awkward in quite a 
few different ways:

A. This is in "active button state" which is conceptually a stronger 
state than just an "active state". E.g., the pointer can now be 
captured. The analogous state for a "pencil" mode is only "active 
state" and not "active button state". An eraser is intuitively a 
destructive mode, so should never have a stronger effect than the 
corresponding "constructive" mode IMO.

B. At the moment of the flip to the eraser mode, if the pen stayed 
within the range of the digitizer, the pen moved from "inactive" to 
"active button state". The [current spec 
wording](https://w3c.github.io/pointerevents/#the-pointerdown-event) 
means the UA needs to fire a <code>pointerdown</code>. So, one could 
click a button by just flipping to eraser mode!

C. If the pen momentarily moves away from the digitizer range during 
the flip to the eraser mode, it can possibly feel like a new stylus 
device with a button already pressed. If that is the case, will the 
very first event be a <code>pointermove</code> and not a 
<code>pointerdown</code> because the new device never switched its 
button state? This is a corner case for hovering buttons that we 
[narrowly 
missed](https://github.com/w3c/pointerevents/issues/14#issuecomment-228114322).

A quick web search reveals we have examples to support the change: 
many (most?) low (OS/device) level APIs treat eraser mode as a new 
device type similar to mouse/pen. Examples:
- [EPointerType=EEraser in Wacom developer's guide for 
Mac](http://www.wacomeng.com/mac/Developers%20Guide.htm),
- [TOOL_TYPE_ERASER in 
Android](https://developer.android.com/reference/android/view/MotionEvent.html#TOOL_TYPE_ERASER),
 and
- [BTN_TOOL_RUBBER in 
Linux](http://lxr.free-electrons.com/source/include/uapi/linux/input-event-codes.h#L401).


Please view or discuss this issue at 
https://github.com/w3c/pointerevents/issues/134 using your GitHub 
account

Received on Wednesday, 24 August 2016 20:41:25 UTC