07:53:56 <RRSAgent> RRSAgent has joined #pointerevents
07:53:56 <RRSAgent> logging to http://www.w3.org/2016/09/20-pointerevents-irc
07:54:43 <rbyers> Present+ Rick_Byers
07:54:50 <NavidZ> Present+ Navid_Zolghadr
07:54:50 <patrick_h_lauke> present+ patrick_h_lauke
07:54:54 <smaug> Present+ Olli_Pettay
07:55:02 <shepazu> present+ shepazu
07:55:51 <takeshi_> takeshi_ has joined #pointerevents
07:56:03 <teddink> present+ teddink
07:56:11 <shepazu> scribenick: teddink
07:56:11 <patrick_h_lauke> rick: priority for group is now to look at outstanding issues we have for level 2 and go to rec
07:57:42 <rbyers> Topic: historical points API: https://github.com/w3c/pointerevents/issues/22
07:59:40 <patrick_h_lauke> [rick shows us android's "getHistorical..." API to get history of touches
07:59:57 <teddink> scribe+ teddink
08:01:04 <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]
08:01:31 <teddink> Rick also showing us the iOS TouchCanvas API set
08:02:38 <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"
08:04:36 <patrick_h_lauke> [discussion on sending single event vs all events]
08:04:48 <patrick_h_lauke> Olli: in Gecko we have times where we send too many events
08:05:21 <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
08:05:33 <patrick_h_lauke> Rick: but you want to avoid backing up a whole queue of events
08:06:33 <patrick_h_lauke> Rick: most engines do some of the coalescing of events
08:07:27 <teddink> Rick: Also tied in with issues #9 - https://github.com/w3c/pointerevents/issues/9
08:09:02 <patrick_h_lauke> Rick: what we do with historical events we'd also want consistency with predicted future events
08:09:42 <teddink> 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.
08:10:01 <patrick_h_lauke> [Rick writes some pseudocode of how an API for getHistoricalPoints would look like]
08:11:14 <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
08:12:08 <patrick_h_lauke> Rick: android interpolates and extrapolates a synthetic point at the v-sync timestamp
08:12:50 <patrick_h_lauke> Rick: might have timestamp issues - is it valid to have historical point that has timestamp > event timestamp
08:13:13 <patrick_h_lauke> Rick: but we could spec this that if timestamp greater, treat as future/predicted point
08:15:13 <patrick_h_lauke> Rick: clientX/Y, screenX/Y, timestamp, tilt, twist, etc - pointerId, isPrimary, pointerType is possibly redundant
08:15:36 <patrick_h_lauke> Rick: (you'd want clientX/Y etc, but not pointerId etc)
08:15:56 <patrick_h_lauke> Olli: but perhaps you'd want everything in the event, including pointerId etc
08:16:12 <patrick_h_lauke> Patrick: so you can just run the same function on a "real" event and a historical point
08:16:22 <patrick_h_lauke> Olli: problem will be event target
08:18:39 <patrick_h_lauke> Navid: and methods won't work (so you don't call getHistoricalPoints on historical points)
08:19:05 <teddink> 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
08:19:56 <patrick_h_lauke> Olli: i guess UAs already optimize events already / GC
08:20:32 <patrick_h_lauke> Navid: should last point be included in the history
08:20:51 <patrick_h_lauke> Rick: iOS API is only about coalesced points NOT including current point
08:21:13 <teddink> 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.
08:24:21 <patrick_h_lauke> Rick: so sounds like we;'re happy with the design that gives an array of (unsent) events
08:24:50 <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
08:25:18 <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
08:25:47 <patrick_h_lauke> Doug: what are security implications of knowing where exactly a user has been?
08:26:15 <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
08:27:27 <patrick_h_lauke> Olli: it doesn't need to be a frozen array, as you could shift entries as you progress through them
08:27:40 <patrick_h_lauke> Rick: advantage of frozen is that if it's called multiple times, it can be cached
08:28:19 <patrick_h_lauke> Rick: i'd rather perhaps have a method
08:28:44 <patrick_h_lauke> Rick: key though: lots of code today copies the full set of properties of an event, example of gmail
08:30:10 <teddink> We also discussed related Issue #38 - predicted points - https://github.com/w3c/pointerevents/issues/38
08:31:51 <patrick_h_lauke> https://github.com/w3c/pointerevents/issues/22
08:35:13 <patrick_h_lauke> [discussion on naming ... coalesced or historical?]
08:35:26 <patrick_h_lauke> Patrick: i'd prefer technically more accurate term
08:35:38 <patrick_h_lauke> Rick: iOS uses coalesced, Android uses historical
08:35:53 <patrick_h_lauke> Ted: windows uses frame history
08:36:19 <patrick_h_lauke> Rick: should we say we go with coalesced
08:36:28 <patrick_h_lauke> and bikeshed more later
08:37:20 <patrick_h_lauke> as this is a fairly specialized use case
08:38:57 <patrick_h_lauke> Rick: we'll start experimenting with an implementation in Chrome
08:39:25 <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)
08:39:41 <patrick_h_lauke> Olli: prefer keeping in PE for now
08:39:45 <patrick_h_lauke> Rick: agreed
08:43:07 <patrick_h_lauke> [Ted and Navid pick up discussion from yesterday briefly about difference between lostpointercapture in Chrome/Edge]
08:44:43 <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
08:48:00 <patrick_h_lauke> https://github.com/w3c/pointerevents/issues/142
08:49:19 <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
08:50:09 <patrick_h_lauke> Rick: we should consider adding this explicitly to spec, but let's wait to see result of bug
08:51:31 <patrick_h_lauke> https://github.com/w3c/pointerevents/issues/135
08:51:56 <patrick_h_lauke> relationship to pointerlock
08:55:03 <patrick_h_lauke> Rick: pointerlock only applicable for mouse
08:56:02 <patrick_h_lauke> Ted: but pointerlock is also useful to hide cursor
09:05:39 <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]
09:06:09 <patrick_h_lauke> Rick: quesiton about how pointerlock interacts with html5 drag'n'drop
09:07:07 <patrick_h_lauke> s/pointerlock/pointercapture
09:09:47 <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
09:10:26 <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
09:10:41 <patrick_h_lauke> NAvid: if capture is in process, d'n'd can't interfere with that
09:11:33 <patrick_h_lauke> [Rick looking at d'n'd events/spec]
09:13:28 <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
09:15:14 <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
09:17:11 <patrick_h_lauke> rrsagent, make logs world-visible
09:22:59 <patrick_h_lauke> rrsagent, make minutes
09:22:59 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-pointerevents-minutes.html patrick_h_lauke
09:23:08 <patrick_h_lauke> rrsagent, bye
09:23:08 <RRSAgent> I see no action items