Re: Hover click with pointer events

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

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.

Mustaq



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

> On 15/06/2015 13:48, Patrick H. Lauke wrote:
>
>> On 22/04/2015 15:47, Timothy Dresser wrote:
>>
>>> The pointer event spec currently has no way of expressing a button press
>>> on a hovering pen
>>> (https://w3c.github.io/pointerevents/#dfn-chorded-buttons). There is no
>>> allowed value for |buttons| if a pen is hovering with a button pressed.
>>>
>>> This is supported by modern styli, for instance the Wacom Bamboo has a
>>> "Hover Click" feature (described on page 43 of
>>>
>>> http://us.wacom.com/~/media/WTC/Files/Manuals/Legacy/Bamboo%20Pen%20Bamboo%20Touch%20Bamboo%20Fun.pdf
>>> ).
>>>
>>>
>>> Is this a scenario we want to enable?
>>>
>>
>> I'd actually love to see this scenario enabled (being able to get button
>> states on hovered stylus/pen).
>>
>>  From some basic testing I just did with a Surface 3 and Surface Pen, it
>> seems that the "eraser" and "right-click" buttons are not passed on when
>> hovering (though in the case of the latter, Windows itself does
>> recognise that it's pressed, as it displays an additional visual circle
>> indicator on the "dot" that normally appears when hovering close enough
>> to the screen). It's only once the pen tip touches the screen that
>> e.buttons changes accordingly. (IE11/Win8.1 - don't have any means of
>> testing the pen on a Win10/Edge setup just yet).
>>
>
> Expanding on this further, I think there are two aspects here, based on
> the current state of the spec and implementation:
>
> a) should button states (button/buttons) be exposed also for "hovering"
> pens, not just for "Pen contact..." cases? In principle, I'd love to see
> this - and currently, at least on Surface 3 + Surface Pen, this is not the
> case (getting a pen into "hover" range fires pointerover, moving it fires
> pointermove, moving the pen out of the detection range fires pointerout ...
> but, regardless of the state of the buttons on the pen, button/buttons is
> not changed)
>
> b) should devs be able to detect the difference between a hovering pen and
> a pen that has contact (in general), so as to be able to then differentiate
> a hovering click vs a touching click (specifically)? This would likely
> require an additional property on the event... e.contact?
>
>
> 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
>
>