Re: Hover click with pointer events

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.

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.

On a related note, shouldn't we have a button value defined for "eraser"
(as for barrel)?

Thoughts?
   Rick



On Tue, Jun 16, 2015 at 9:14 AM, Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> On 16/06/2015 17:02, Mustaq Ahmed wrote:
>
>>  From a different perspective, the PE spec has events only for
>> change-of-state with respect to the touch surface (pointerup,
>> pointermove, ...), and we piggyback button-change states to those
>> events. I think to support the hover-button-changes, we /need/ a
>> separate event, like "buttonchange" or "hoverchange". The "buttonchange"
>> event would also make sense for a touching pen that is not moving.
>>
>
> Note that pointerover, pointermove and pointerout fire (and are per spec,
> or rather the spec does not explicitly mention that they need to be only
> for pen contact) for hovering pointers (on Surface 3 anyway). So I don't
> think the "respect to the touch surface" part is accurate.
>
> Scott pointed out (on IRC) that the spec also currently states that a
> button state change is meant to fire a pointermove - see
> https://w3c.github.io/pointerevents/#h-the-pointermove-event
>
> "Additionally, when a pointer changes button state, pressure, tilt, or
> contact geometry (e.g. width and height) and the circumstances produce no
> other pointer events defined in this specification then a user agent must
> fire a pointer event named pointermove."
>
>
>  For Patrick's Question (b), tracking "pointerup" and "pointerdown"
>> should be enough to differentiate between a pen's hovering vs touching
>> states, right? Then a "buttonchange" could represent the "click" in
>> either state. I am assuming you meant by "click" a button-press, not a
>> "surface-touched" event.
>>
>
> When mentioning "click", I just picked up on the OT talking about "Hover
> Click" interactions...but more generally, I was also thinking about being
> able to easily differentiate between a pointermove that is happening for a
> hovered stylus vs a stylus that has pen contact on the touchscreen.
>
> Sure, manually keeping track of pointerup/pointerdown is easily done, but
> wondered if there's any mileage in simply exposing a property (which would
> greatly reduce the need for devs to track event flows). To me, whether a
> stylus is touching or not touching the surface is simply another property
> akin to its orientation, position, pressure, etc, so philosophically it
> would make sense to me to have it as a property. Thoughts?
>
> Or should a hovering stylus have a specific pressure? (not tested, perhaps
> this is already the case in Surface 3...a pressure of 0 perhaps? or -1 to
> make absolutely sure it's not simply lightly resting on the touch surface?)
>
>
> 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
>
>