<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

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: patrick_h_lauke smaug BoCupp NavidZ
No ScribeNick specified.  Guessing ScribeNick: patrick_h_lauke
Found Scribe: Patrick H. Lauke
Agenda: https://lists.w3.org/Archives/Public/public-pointer-events/2019AprJun/0024.html

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)