Re: Hover click with pointer events

On Tue, Jun 16, 2015 at 10:26 AM, Tim Dresser <tdresser@google.com> wrote:

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

Whoops, how did I miss that?  I swear I did "find in page".  Oh well.

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.
>

Remember that we want device-agnostic code to "just work" to re-using
button=0 to mean "primary activation" for all input devices is a good thing
IMHO.

 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
>>>
>>>
>>