Minutes from the Pointer Events WG call 15 May 2019

Dear all,

thanks for joining the call. The minutes are at 
https://www.w3.org/2019/05/15-pointerevents-minutes.html and copied below:

Pointer Events Working Group
15 May 2019
Agenda

Attendees
Present
patrick_h_lauke, smaug, BoCupp, NavidZ
Regrets
Chair
Patrick H. Lauke
Scribe
Patrick H. Lauke
Contents
Topics
are we ready for moving to v3 / FPWD
* Should "click", "dblclick" and "contextmenu" events be PointerEvents?: 
Since MS folks had a suggestion that they had tried this before for 
click and it seemed useful, I was wondering whether we should pursue 
this and whether there is developer interest for it 
https://github.com/w3c/pointerevents/issues/100
Consider a simple API for low-latency pointer trails 
https://github.com/w3c/pointerevents/issues/211
Summary of Action Items
Summary of Resolutions
<scribe> Scribe: Patrick H. Lauke

are we ready for moving to v3 / FPWD
NavidZ: we have TAG reviewing a few things currently, should be ready in 
about a week

Olli: would be good to have in some form of public working draft yes

Patrick: guessing we'll need to spend time working out how to graft 
extension onto actual spec, but once done we can move ahead with FPWD

NavidZ: i'll make a pull request, we can discuss this there and then get 
it moved to FPWD

* Should "click", "dblclick" and "contextmenu" events be PointerEvents?: 
Since MS folks had a suggestion that they had tried this before for 
click and it seemed useful, I was wondering whether we should pursue 
this and whether there is developer interest for it 
https://github.com/w3c/pointerevents/issues/100
NavidZ: it caused some compatibility issue at the time. pressure etc 
would be 0, but type etc will be new
... we should consider doing this if there's any use for doing it / 
developer interest. otherwise there's more compat risk for no gain
... folks from Microsoft have any input on this?

BoCupp: will follow up with Matt Rakow (?) about historically why the 
decision was made

Olli: there was question also about drag events and whether they should 
be pointer events, but for inheritance they can't be
... should we keep them as they are, since we can't make them pointer 
events due to the different properties of the event

NavidZ: should check with UI Events folks
... do we have any actual real need, or just for consistency?

Olli: agree without use cases it makes little sense to pursue

<NavidZ_> Extend pointer events to support raw trackpad data: I remember 
some

<NavidZ_> discussions with Matt back in TPAC 2016 ish that MS was 
interested in

<NavidZ_> exposing a new pointerevent type for this. I was wondering 
whether they

<NavidZ_> are still interested and whether there are potential customers 
for this.

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

Extend pointer events to support raw trackpad data: I remember some 
discussions with Matt back in TPAC 2016 ish that MS was interested in 
exposing a new pointerevent type for this. I was wondering whether they 
are still interested and whether there are potential customers for this. 
https://github.com/w3c/pointerevents/issues/206

NavidZ: again, this originally came from MS. wondering if there's any 
customer need

BoCupp: will also check with Matt

Patrick: need to double-check Bo and Grisha are on the right mailing lists

<NavidZ_> * touch-ACTION: scroll || scroll-x || scroll-y

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

NavidZ: this was actually requested by a developer, so author need

<NavidZ_> We have an alternate proposal for this

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

NavidZ: this crosses over with another event specifically for 
overscroll. seems the need for the developer is met by this other 
specification

(proposal, not specification)

NavidZ: feels like we don't need to do anything in PE if it's addressed 
by this other proposal

Olli: would be good to get more feedback on the issue, just to check. 
the issue seems 2 years old though

NavidZ: going to try to get in touch with original poster as have been 
in contact with them

Consider a simple API for low-latency pointer trails 
https://github.com/w3c/pointerevents/issues/211
NavidZ: filed early on, but we then had other proposals, like pointerraw 
and predicted events, and those feel more in line with / flexibility for 
the proposed use case

<NavidZ_> Correct link to the issue:

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

Patrick: to me this sounds too complex for what it wants to do, while 
not going far enough / flexible enough, so gut feeling is that if an app 
wanted to do something like trails they'd be better off doing it custom 
with raw events etc

BoCupp: Microsoft does have an interest here due to some device 
combinations where latency is an issue, and having something more 
low-level would help with offloading some of the "feel" of 
responsiveness. ("wet" stroke vs "dry" stroke)
... you may want to give a visual hint of where the tip of the pen 
touches the drawing surface, even though it's not a stroke that you can 
actually make/draw (?) so this would help provide this feedback

NavidZ: what would be the best API to fill the gap between where your 
pen is touching and what the app can actually draw

BoCupp: would need more thinking, but it could take various forms (e.g. 
drawing some intermediate line/point between where the last actual 
drawing happened and where the pen is now)

NavidZ: is this something you'd want to have in v3, or too early?

BoCupp: we can try taking that forward

Patrick: will also need to check with PLH about being associated with 
the repo so an issue can be assigned to Bo

-- 
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, 15 May 2019 17:31:34 UTC