Minutes from Pointer Events WG call 10 July 2019

Dear all,

minutes from today's call available on 
https://www.w3.org/2019/07/10-pointerevents-minutes.html and copied below:

Pointer Events Working Group
10 Jul 2019
Agenda 
https://lists.w3.org/Archives/Public/public-pointer-events/2019JulSep/0011.html

Attendees
Present
patrick_h_lauke, BoCupp, smaug, ella, mustaq, NavidZ, Navid
Regrets
Chair
Patrick H. Lauke
Scribe
patrick_hlauke
Contents
Topics
Extend pointer events to support raw trackpad data 
<https://github.com/w3c/pointerevents/issues/206>
Too many other behaviors interrupt pointer events (dragstart, 
touch-action)<https://github.com/w3c/pointerevents/issues/213>
touch-action: scroll || scroll-x || 
scroll-y<https://github.com/w3c/pointerevents/issues/211>
Mouse back/forward buttons: page navigation or JS events? 
<https://github.com/w3c/pointerevents/issues/191
Summary of Action Items
Summary of Resolutions
<scribe> Scribe: patrick_hlauke

<smaug> just a sec

<smaug> hmm, I can't hear anything..

we could hear you typing

Extend pointer events to support raw trackpad data 
<https://github.com/w3c/pointerevents/issues/206>
Bo: had meeting with owner of trackpad API internally, potential 
additional scenario of using trackpad as signature. integration-wise, it 
gets hairy as you'd need a side channel from the human interface device 
and your app would end up fighting with the native/OS side

we don't have apps natively that consume raw data, only consume data 
after OS consumed it/made it available. but have had digital signature 
requests, but not acted on them yet

as we don't have native apps doing this, this can inform how pressing 
(or not) it would be for web platform / PE

mustaq: we have bugs open. we had issue with signature for pdf viewer 
and problem with passing things through

Bo: from MS perspective we don't have people asking for this, so would defer

Olli: agree we can close or at least remove v3 label

Patrick: we can close it now, worst case we can reopen in future if new 
use cases/insights emerge

Too many other behaviors interrupt pointer events (dragstart, 
touch-action)<https://github.com/w3c/pointerevents/issues/213>
Patrick: no further work has happened yet (may need NavidZ to confirm). 
we'll discuss next meeting

touch-action: scroll || scroll-x || 
scroll-y<https://github.com/w3c/pointerevents/issues/211>
Patrick: seems that user wants overscroll behaviour/detection

mustaq: this doesn't fit the pointer event model as the pointer gets 
cancelled, would you bring it back later?

Bo: looks like starting a new sequence on overscroll

https://discourse.wicg.io/t/proposal-new-events-for-overscroll-and-scrollend/3481

<ella> 
https://discourse.wicg.io/t/proposal-new-events-for-overscroll-and-scrollend/3481

https://navidz.github.io/overscroll-scrollend-events/ this 404s

<mustaq> From the linked post:

<mustaq> https://www.irccloud.com/pastebin/w98kSxsK/

Proposal

Dispatch the overscroll and scrollend events in addition to the scroll 
event to provide more states to the javascript code. Note that 
overscroll event needs a delta as while the user is overscrolling 
nothing changes (in terms of offsetX/Y) and hence the script will need 
the delta in the event to get more information.

<BoCupp> Is this the link for the alternative proposal? 
https://github.com/WICG/overscroll-scrollend-events

Patrick: that's probably it yes

Bo: there's discussion around pick a use case and show how developer 
uses the API, reverse the overscroll, etc

Patrick: conceptually, is this something for Pointer Events to handle, 
or do we want to defer to this proposed new spec?

mustaq: the assumption here is that the pointer that gets cancelled is 
the one that comes back
... how would the dev differentiate it from a different pointer being down

Olli: use case needs to be implemented without touch action, websites 
would need to do it themselves

mustaq: ... we send an "uncancel" evenent (?) to the application for the 
same pointer. js gives control to browser, but then browser needs to 
give control back to JS ...

Olli: i don't think that's feasible to do within PE
... they'll have to do the whole thing in JS, without interacting 
(handing on/off) with user agent behavior

Bo: there's room though for using browser smooth scrolling without 
having to replicate all this in JS, but agree this seems less natural as 
treating it as another pointerdown
... compared to what Navid proposes with new events and a delta

Olli: does this apply to keyboard scrolling too. it's only for pointers, 
so should it be in pointer events

Patrick: it's about seeing if it#s PE because it only happens with 
pointers, or do we look at this as it's about scrolling
... can we overscroll with a mousewheel? can't overscroll with keyboard

<mustaq> Ella: in Chrome no way to overscroll using mousewheel or keyboard

Bo: in the proposal for overscroll it says it needs to take into 
consideration various input methods
... getting back to question before, do we want to keep working on this 
in PE or leave it at WICG? latter has more discussion, and seems that 
this will touch on more than just pointers

Patrick: agree. Olli, mustaq, any objections?

no objections

Patrick: i'll close the issue and point to the minutes here. it may come 
back here once it's been discussed further in WICG

<mustaq> Next:

<mustaq> https://github.com/w3c/pointerevents/issues/191

Mouse back/forward buttons: page navigation or JS events? 
<https://github.com/w3c/pointerevents/issues/191
Patrick: this sounds like it's a shortcut that happens at OS level 
unless an app explicitly opts into getting the buttons themselves rather 
than just commands

Bo: correct. users can't change the command itself unless they use 
customisation software for mouse/keyboard, but in principle yes apps can 
opt into receiving the buttons
... signals from OS can also be cancelable, where the app gets both the 
command and the button press and can decide what to do
... we'd opt for option B

mustaq: concern about button doing different things depending on where 
the user clicks
... but if it's only a small concern, we'd go for B

Olli: but is this web compatible?
... i.e. pages could cancel all button down, but only process "regular" 
buttons, which would then prevent the expected navigation command/action

Bo: how would we solve this? have sites opt in?

<ella> https://www.chromestatus.com/feature/5088301178421248

PAtrick: i don't think we do any kind of opt in for other stuff, other 
than via touch-action directives. worth running an experiment/analysing 
web content/sites?

mustaq: i believe we now allow cancelling (bug above posted by ella)

Olli: should the default event be on down or up or click or auxclick

ella: we have a test page

<ella> https://jsbin.com/cawumemaqu/edit?html,output

<ella> from crbug.com/852709

Olli: think we need more info on how OSs work right now/when they fire 
the default. could expect safari folks wouldn't want to do anything that 
doesn't map to MacOS behavior

mustaq: we've not received complains about the new behavior (?)

Olli: would be nice to know exact behavior chrome has right now

Patrick: we can leave it for next time

<NavidZ_> https://github.com/w3c/pointerevents/issues/203

[discussion on starting merging extension into main doc in a branch for 
v3 - Navid will take care of this]

Bo: another topic we'd like to look at is Enable direct pen and touch to 
have different touch-action behavior 
https://github.com/w3c/pointerevents/issues/203
... [explains scenarios where you'd want specific control over pen 
rather than all pointers with touch-action just now]
... written an explainer with more use cases

Patrick: this kind of highlights the misnomer of touch-action which 
actually applies to all pointers (in theory at least, UAs don't do 
special things on mouse, but they do stuff for touch and pen)
... i mean we could do some heuristic/mapping (if only touch-action is 
there, treat it like "high-level" action - like pointer-event-action - 
but otherwise only apply it to touch if there's a pen-action)

<mustaq> Dev proposal here: 
https://github.com/w3c/pointerevents/issues/203#issuecomment-299578767

Navid: agree we could for compat provide some kind of compat way. or do 
we want a breaking change
... in terms of forward compatibility, where more input types / pointers 
may emerge, it feels weird to go down the touch-action, pen-action, etc 
way of having to create a new css property. if we are 
inventing/expanding the css property, then maybe good to invent a new 
css thing that can apply to everything, and then merge the touch action 
values as legacy

Patrick: agree we want to look at a more input agnostic approach

Bo: i can take this away and see if we can come up with something more 
general

Navid: may also want to talk to CSS WG. maybe discuss further at TPAC?




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

Received on Wednesday, 10 July 2019 16:11:35 UTC