<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

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.