Re: Hover click with pointer events

Rick, this <https://w3c.github.io/pointerevents/> version of the spec does
define a button value for "eraser".

I'm in favor of allowing the 'buttons' state to change while hovering. If
we were starting from scratch, I think viewing pointer contact as another
value in the 'buttons' bitfield would make the most sense. Since the
'buttons' value '0' currently indicates contact, we can't easily take that
route at this point.

 I'd be fine with forcing developers to listen for pointerup/pointerdown
events to keep track of hover.

On Tue, Jun 16, 2015 at 12:43 PM Rick Byers <rbyers@chromium.org> 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.
>
> 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
>>
>>
>