Minutes from PEWG F2F at TPAC 20 Sept

Dear all,

rough minutes from today's F2F are here 
https://www.w3.org/2016/09/20-pointerevents-minutes.html and copied below.

(apologies for not having sent out the minutes from yesterday, but need 
to somehow locate them after my laptop completely died at the end of 
meeting before i was able to run the RRSAgent incantations to generate them)

W3C
- DRAFT -

SV_MEETING_TITLE

20 Sep 2016

See also: IRC log

Attendees

Present
Rick_Byers, Navid_Zolghadr, patrick_h_lauke, Olli_Pettay, shepazu, teddink
Regrets
Chair
SV_MEETING_CHAIR
Scribe
teddink
Contents

Topics
historical points API: https://github.com/w3c/pointerevents/issues/22
Summary of Action Items
Summary of Resolutions
<shepazu> scribenick: teddink
<patrick_h_lauke> rick: priority for group is now to look at outstanding 
issues we have for level 2 and go to rec
historical points API: https://github.com/w3c/pointerevents/issues/22

<patrick_h_lauke> [rick shows us android's "getHistorical..." API to get 
history of touches
scribe+ teddink

<patrick_h_lauke> [context: observer from Sony joined meeting to discuss 
possibility of adding PE to their e-ink based annotation tablet, but 
wondering about getting history for PE similar to what can be done at 
lower level on Android etc]
Rick also showing us the iOS TouchCanvas API set

<patrick_h_lauke> Rick: getting history is useful for handwriting/drawin 
scenarios - if there's some JS jank, you can ask "what was the 
historical sequence of events/coords/etc"
<patrick_h_lauke> [discussion on sending single event vs all events]
<patrick_h_lauke> Olli: in Gecko we have times where we send too many events
<patrick_h_lauke> Rick: for general situations like carousels etc, you 
don't necessarily need ALL events, but for art case/text 
recognition/etc, you want precision
<patrick_h_lauke> Rick: but you want to avoid backing up a whole queue 
of events
<patrick_h_lauke> Rick: most engines do some of the coalescing of events
Rick: Also tied in with issues #9 - 
https://github.com/w3c/pointerevents/issues/9

<patrick_h_lauke> Rick: what we do with historical events we'd also want 
consistency with predicted future events
Rick clarified that the API essentially provides the events that would 
have been fired between the previous event and the current event. Once 
an event is fired, however, you cannot go back to the previous event, 
just the coalesced events between the last and the current event.

<patrick_h_lauke> [Rick writes some pseudocode of how an API for 
getHistoricalPoints would look like]
<patrick_h_lauke> Olli: if we get different type of history, of data, 
we'll get compat issues on sites that expect a particular format/frequency
<patrick_h_lauke> Rick: android interpolates and extrapolates a 
synthetic point at the v-sync timestamp
<patrick_h_lauke> Rick: might have timestamp issues - is it valid to 
have historical point that has timestamp > event timestamp
<patrick_h_lauke> Rick: but we could spec this that if timestamp 
greater, treat as future/predicted point
<patrick_h_lauke> Rick: clientX/Y, screenX/Y, timestamp, tilt, twist, 
etc - pointerId, isPrimary, pointerType is possibly redundant
<patrick_h_lauke> Rick: (you'd want clientX/Y etc, but not pointerId etc)
<patrick_h_lauke> Olli: but perhaps you'd want everything in the event, 
including pointerId etc
<patrick_h_lauke> Patrick: so you can just run the same function on a 
"real" event and a historical point
<patrick_h_lauke> Olli: problem will be event target
<patrick_h_lauke> Navid: and methods won't work (so you don't call 
getHistoricalPoints on historical points)
Windows API that could provide the raw data for this API: 
https://msdn.microsoft.com/en-us/library/windows/desktop/hh454880(v=vs.85).aspx

<patrick_h_lauke> Olli: i guess UAs already optimize events already / GC
<patrick_h_lauke> Navid: should last point be included in the history
<patrick_h_lauke> Rick: iOS API is only about coalesced points NOT 
including current point
There are similar API's in Windows for both pen and touch - so a UA may 
need to use multiple all of them to get all of the relevant data to fill 
in the full pointer event object.

<patrick_h_lauke> Rick: so sounds like we;'re happy with the design that 
gives an array of (unsent) events
<patrick_h_lauke> Patrick: I wonder if this is something that should be 
spec'd at a higher level, i.e. not in PE but perhaps in...input WG in 
general
<patrick_h_lauke> Rick: the only scenarios where you really want this is 
touch/mouse/stylus, so argument maybe is if this should also be spec'd 
for touch events
<patrick_h_lauke> Doug: what are security implications of knowing where 
exactly a user has been?
<patrick_h_lauke> Rick: security implication is minimal as you don't get 
it across page loads etc, it's just for a small timeframe of events that 
weren't sent
<patrick_h_lauke> Olli: it doesn't need to be a frozen array, as you 
could shift entries as you progress through them
<patrick_h_lauke> Rick: advantage of frozen is that if it's called 
multiple times, it can be cached
<patrick_h_lauke> Rick: i'd rather perhaps have a method
<patrick_h_lauke> Rick: key though: lots of code today copies the full 
set of properties of an event, example of gmail
We also discussed related Issue #38 - predicted points - 
https://github.com/w3c/pointerevents/issues/38

<patrick_h_lauke> https://github.com/w3c/pointerevents/issues/22
<patrick_h_lauke> [discussion on naming ... coalesced or historical?]
<patrick_h_lauke> Patrick: i'd prefer technically more accurate term
<patrick_h_lauke> Rick: iOS uses coalesced, Android uses historical
<patrick_h_lauke> Ted: windows uses frame history
<patrick_h_lauke> Rick: should we say we go with coalesced
<patrick_h_lauke> and bikeshed more later
<patrick_h_lauke> as this is a fairly specialized use case
<patrick_h_lauke> Rick: we'll start experimenting with an implementation 
in Chrome
<patrick_h_lauke> Patrick: now question is if we should also try to add 
this to touch events (as TECG membership is mostly same as PEWG)
<patrick_h_lauke> Olli: prefer keeping in PE for now
<patrick_h_lauke> Rick: agreed
<patrick_h_lauke> [Ted and Navid pick up discussion from yesterday 
briefly about difference between lostpointercapture in Chrome/Edge]
<patrick_h_lauke> Ted: (summarising) there's possibility of harmonizing 
behavior with what Chrome does, as current implementation doesn't sound 
worrysome - just way in which we decided to map OS events to UA events
<patrick_h_lauke> https://github.com/w3c/pointerevents/issues/142
<patrick_h_lauke> Ted: difference in event order not a BIG issue, but it 
may catch out some scenarios (e.g. 3rd party library devs) who happen to 
rely on it when they should't
<patrick_h_lauke> Rick: we should consider adding this explicitly to 
spec, but let's wait to see result of bug
<patrick_h_lauke> https://github.com/w3c/pointerevents/issues/135
<patrick_h_lauke> relationship to pointerlock
<patrick_h_lauke> Rick: pointerlock only applicable for mouse
<patrick_h_lauke> Ted: but pointerlock is also useful to hide cursor
<patrick_h_lauke> [tangent of how to remove cursor - CSS cursor has some 
security checks in browsers to avoid completely/mostly transparent 
cursors; pointerlock makes sense for mouse only, but can be used for 
stylus to hide cursor like in Patrick's WebGL stylus demo]
<patrick_h_lauke> Rick: quesiton about how pointercapture interacts with 
html5 drag'n'drop
<patrick_h_lauke> Rick: difficult to write this in spec, as we want to 
allow user to have explicit drag'n'drop (on long-press in case of 
touch), but normally we wouldn't want captured pointers to participate 
drag'n'drop
<patrick_h_lauke> Doug: key is if there's a d'n'd operation in progress. 
however you got there, if you're already dragging, it takes precedence
<patrick_h_lauke> NAvid: if capture is in process, d'n'd can't interfere 
with that
<patrick_h_lauke> [Rick looking at d'n'd events/spec]
<patrick_h_lauke> Rick: is this just question of order? if you capture 
first then start d'n'd, you d'n'd. if you started drag, and then tried 
to capture, you'd want to prevent d'n'd
<patrick_h_lauke> if you wanted to stop d'n'd you WOULD preventDefault 
on pointerdown normally, BUT if you tried capturing that should also 
stop d'n'd
Summary of Action Items

Summary of Resolutions

[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/09/20 09:23:04 $
Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/pointerlock/pointercapture/
Found ScribeNick: teddink
Inferring Scribes: teddink
Present: Rick_Byers Navid_Zolghadr patrick_h_lauke Olli_Pettay shepazu 
teddink

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 20 Sep 2016
Guessing minutes URL: 
http://www.w3.org/2016/09/20-pointerevents-minutes.html
People with action items:

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


[End of scribe.perl diagnostic output]




-- 
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 Tuesday, 20 September 2016 17:18:59 UTC