RE: Hover click with pointer events

On Tue, Jun 16, 2015 at 10:26 AM, Tim Dresser <tdresser@google.com> wrote:
>
> Rick, this 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. 

Yeah I agree. This seems like the safest place to start.  I opened up an issue to track this and will take a look at a spec patch to address this.

https://github.com/w3c/pointerevents/issues/14 

On Tue, Jun 16, 2015 at 10:30 AM, Rick Byers <rbyers@chromium.org> wrote:
>
> On Tue, Jun 16, 2015 at 10:23 AM, Patrick H. Lauke <plauke@paciellogroup.com> wrote:
>>
>> On 16/06/2015 17:42, Rick Byers 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.
>>
>>
>> The "barrel button" is supposed to be equivalent to right-mouse/context menu. As such, when pressed in the air, it should just fire pointermove (as per spec) and click, rather than pointerup / pointerdown.

Only when you press the button *and* tap the screen. Hover clicking the barrel button doesn't open a context menu. So I don't think it should fire click in this case either. But we should update buttons on the move events. If we're not firing click in these cases, then I don't anticipate a major compat issue with populating buttons during hover.  My primary question is whether Windows pointer messages have this data populated.  I'll need to try under the debugger and see what's up.

>> Same for any "left-mouse button" type buttons (Surface Pen lacks this - it only has barrel, erase, and the non-remappable Microsoft OneNote one at the top https://www.microsoft.com/surface/en-gb/support/touch-mouse-and-search/surface-pen  - but Wacom Bamboo does have it - left-click, right-click, erase http://us.wacom.com/~/media/WTC/Files/Manuals/Legacy/Bamboo%20Pen%20Bamboo%20Touch%20Bamboo%20Fun.pdf/ (p 43)). Fire pointermove and click.
>>
>>> 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.
>>
>>
>> For left-mouse button and right-mouse button / activation and barrel, and possibly also for erase, would devs also be able to just listen for click as usual? (not tested, but: does click in theory also have the same button/buttons that you'd get from listening to pointermove instead?)
>
>
> Do we really want to fire 'click' without pointerup/pointerdown?  Would that be web compatible?  I was arguing that we wouldn't fire anything other than pointermove here...

No. But I think we should probably have a pointerbuttonschange event for this scenario. That would also be helpful for handling chorded buttons more easily too. In other words, pressing left mouse then right could produce:

pointerdown (left)
pointerbuttonchange (right)
pointerbuttonchange (right up)
pointerup (left up)

Received on Wednesday, 17 June 2015 22:20:12 UTC