15:00:41 <RRSAgent> RRSAgent has joined #pointerevents
15:00:41 <RRSAgent> logging to http://www.w3.org/2016/04/26-pointerevents-irc
15:00:45 <circ-user-eEWFe> present+ Navid_Zolghadr
15:00:58 <shepazu> RRSAgent, start telcon
15:00:58 <RRSAgent> I'm logging. I don't understand 'start telcon', shepazu.  Try /msg RRSAgent help
15:01:05 <shepazu> Zakim, start telcon
15:01:06 <Zakim> I don't understand 'start telcon', shepazu
15:01:49 <shepazu> present+ Rick_Byers
15:02:44 <rbyers> zakim, this will be RWC_PEWG
15:02:44 <Zakim> ok, rbyers
15:03:20 <shepazu> trackbot, start telcon
15:03:22 <trackbot> RRSAgent, make logs 231
15:03:24 <trackbot> Zakim, this will be 7394
15:03:24 <Zakim> ok, trackbot
15:03:25 <trackbot> Meeting: Pointer Events Working Group Teleconference
15:03:25 <trackbot> Date: 26 April 2016
15:03:32 <rbyers> scribenick: dtapuska
15:03:41 <rbyers> scribe: Dave_Tapuska
15:03:43 <shepazu> present+ Rick_Byers
15:03:46 <dtapuska> present+ dtapuska
15:03:52 <shepazu> present+ Navid_Zolghadr
15:03:58 <patrick_h_lauke> present+ patrick_h_lauke
15:03:59 <shepazu> present+ shepazu
15:04:11 <shepazu> present+ Scott_Gonzalez
15:04:16 <patrick_h_lauke> >> * open issues: priority and scope
15:04:16 <patrick_h_lauke> https://github.com/w3c/pointerevents/issues
15:04:16 <patrick_h_lauke> https://github.com/w3c/pointerevents/pulls
15:04:16 <patrick_h_lauke> >> * testing plan and timeline
15:04:17 <patrick_h_lauke> >> * implementation news and plans
15:04:17 <patrick_h_lauke> >> * (suggestions?)
15:04:28 <shepazu> zakim, this will be RWC_PEWG
15:04:28 <Zakim> ok, shepazu
15:04:30 <patrick_h_lauke> >> * Publishing Pointer Events 2 as FPWD (Call for Consensus)
15:04:36 <mustaq> present+ Mustaq_Ahmed
15:04:37 <dtapuska> Chair: Patrick_H_Lauke
15:04:38 <teddink> teddink has joined #pointerevents
15:05:01 <shepazu> Topic: publishing FPWD
15:05:03 <dtapuska> Topic: Publishing Pointer Events 2 as FPWD
15:05:15 <teddink> +present teddink
15:06:05 <dtapuska> shepazu: was muted
15:06:52 <dtapuska> DS: Put out request; make request to domain lead
15:07:41 <dtapuska> ... Prepare for publication; shepazu takes a copy and moves to the correct place in /TR; do some coms stuff.
15:07:52 <dtapuska> ... Send out an email; describe what is different
15:08:18 <dtapuska> ... Does this draft replace #1 or does it build on it?
15:08:32 <dtapuska> PL: It builds on it
15:08:47 <dtapuska> DS: someone coming at it as a blank slate; do they just need to read both?
15:09:10 <dtapuska> PL: No; it builds on it. Since it completely replaces version 1, we just request a short name
15:09:43 <patrick_h_lauke> related: this came out as part of this discussion respec https://github.com/w3c/pointerevents/issues/46
15:10:13 <dtapuska> DS:  We just use a short name. Anyone with github key can push directly to the TR. We should have a call for consensus to make sure everyone agrees
15:10:27 <dtapuska> DS: Keep iterating on it until it goes to CR
15:11:02 <dtapuska> RB: There is value in doing it when the links made sense; when it was valuable to have a short name
15:11:52 <dtapuska> DS: If this draft completely supersedes version #1 we should just do it right away and the newest version should be the one we should be looking at
15:12:15 <dtapuska> RB: Sounds like we should just go through the process; unless anyone objects
15:12:51 <dtapuska> PL: Sounds alright; should move ahead with FPWD
15:13:15 <dtapuska> RESOLUTION: We will issue a call for comments on the mailing list
15:13:28 <dtapuska> DS: 10 day or 2 week call for comments
15:13:57 <dtapuska> Topic: Open issues; pull requests
15:14:10 <patrick_h_lauke> (4:04:25 PM) patrick_h_lauke: https://github.com/w3c/pointerevents/issues
15:14:10 <patrick_h_lauke> (4:04:25 PM) patrick_h_lauke: https://github.com/w3c/pointerevents/pulls
15:14:18 <dtapuska> RB: mustaq posted 4 issues to list
15:14:21 <patrick_h_lauke> We would like to focus on the following 4 issues in this meeting, feel free to add/remove items as needed:- Pointer Id across different iframes: https://github.com/w3c/pointerevents/issues/52
15:14:21 <patrick_h_lauke> - setPointerCapture should say something about iframes: https://github.com/w3c/pointerevents/issues/16- Issue with compatibility mouse events and inconsistency with mouse pointerevent: https://github.com/w3c/pointerevents/issues/35- Determining the primary pointer - note about mice? https://github.com/w3c/pointerevents/issues/49
15:14:31 <rbyers> Topic: Pointer Id across different iframes: https://github.com/w3c/pointerevents/issues/52
15:14:56 <dtapuska> RB: Question here is do we want to say the id is consistent across iframes
15:15:00 <mbrubeck> Present+ Matt_Brubeck
15:15:10 <dtapuska> ... Is it consistent across windows
15:15:23 <dtapuska> ... Edge is consistent across window
15:15:51 <dtapuska> NZ: How does capturing work across iframes; edge has it
15:15:55 <rbyers> setPointerCapture should say something about iframes: https://github.com/w3c/pointerevents/issues/16
15:16:26 <dtapuska> RB: do you know if capturing across iframes is something developers rely on
15:16:49 <dtapuska> RB: question was asked to Ted; about whether there are metrics of something Edge knows.
15:17:13 <dtapuska> RB: NZ posted a proof of concept attack vector
15:17:42 <dtapuska> TD: We need to look into that issue to see the actual issue it was posted only yesterday
15:18:14 <dtapuska> JR: Is it just a case of when pointer is down; you just get the location of the input. What is the security concern
15:19:10 <dtapuska> RB: Example page with a pin pad; an iframe periodically does a request frame animation that periodically grabs the capture. The 'ad' could track the mouse location.
15:19:27 <dtapuska> ... You could monitor the mouse position without interfering much
15:20:04 <dtapuska> JR: We did explore the issue back in the day. Would want to see the issue sketched out a little more
15:20:41 <dtapuska> SC: Is this just a concern pointer capture isn't down
15:21:22 <dtapuska> NZ: Ads/iframes can interfer the rest of the page when the pointer is down
15:21:54 <dtapuska> JR: Ads can interfer with lots of the page; is this really a concern. microphone, full screen, hang perf, is this something we want to protect against
15:22:10 <dtapuska> RB: Ads are moving to Sandboxed iframes
15:22:21 <dtapuska> ... We probably want sandboxed iframes to disallow capture
15:22:49 <dtapuska> NZ: Sandboxed iframes should only allow capture if the pointer is inside the iframe
15:23:07 <dtapuska> RB: Is it important for an iframe to capture a pointer that was never targeted to it
15:24:03 <dtapuska> JR: I reject the idea is as it is based on today. We only want to add restrictions if there is a compelling reason to do so
15:24:40 <dtapuska> RB: I'll take to Chrome's security group we have a lot of things to deal with keyboard focus
15:24:56 <dtapuska> RB: Can we all agree on disallowing for sandbox iframes
15:25:03 <dtapuska> JR: Not sure about that...
15:25:23 <dtapuska> RB: Sandbox iframes are about cross site scripting
15:26:09 <dtapuska> JR: Need to explore the security ramifications. We should not explore this in github; use an offline format that isn't publically visible
15:26:36 <dtapuska> RB: Do we have a method to report issues against Edge that aren't in public domain
15:26:49 <dtapuska> JR: We don't have the ability to do that
15:27:09 <dtapuska> RB: We can use chromium bug tracker to track this
15:27:26 <dtapuska> ACTION: RB to create an issue with relevant people to discuss it there.
15:27:26 <trackbot> Created ACTION-155 - Create an issue with relevant people to discuss it there. [on Rick Byers - due 2016-05-03].
15:28:43 <dtapuska> RB: Need a item in the spec for pointer ids and needs test for it
15:29:17 <dtapuska> TD: Ok with that we rely on the ids from the OS on this. Edge is just because we rely on Windows
15:29:57 <dtapuska> RB: We need to come with an id that follows the rules that and on X11 the ids between mouse and touch can overlap; so Chrome remaps them
15:30:16 <dtapuska> PL: The spec should say it is consistent however it is achieve
15:30:29 <dtapuska> NZ: Is it just iframes are the same or all the windows?
15:31:08 <dtapuska> NZ: What about processes? Windows it is free cause it comes from the OS
15:31:27 <dtapuska> mustaq: What is the scope
15:32:02 <dtapuska> RB: Should this be top level browsing context
15:32:37 <dtapuska> RB: If you had something across browser windows; it would be possible to make something work in Edge but not Chrome
15:32:51 <dtapuska> TD: I've built things like that before
15:33:29 <shepazu> agenda+ telcon frequency
15:33:37 <dtapuska> RB: Doesn't Windows lock the window pointer
15:34:00 <dtapuska> TD: Need to do some experimentation of what we are doing today with respect to drag events
15:34:01 <patrick_h_lauke> http://patrickhlauke.github.io/touch/tracker/multi-touch-tracker-pointer-hud.html
15:34:54 <dtapuska> RB: those drag and drop events are mouse events so they don't have pointer ids
15:35:21 <dtapuska> ... Ted said they do fire drag and drop events across windows. And they are HTML5 drag and drop events
15:35:22 <patrick_h_lauke> from basic testing with two instances of edge, using the above url, when i press mouse down in one then drag mouse to the other window, i don't get pointer/mouse events in the other window
15:35:27 <patrick_h_lauke> may just be specific to mouse
15:35:37 <dtapuska> ... so they don't have a necessary pointer id associated with them
15:36:03 <dtapuska> TD: We did do this for touch; but we need to do some experimentation to verify there
15:36:24 <dtapuska> RB: Can we put a pull request to to say pointer ids are associated with the top level browsing context
15:36:30 <dtapuska> PL: Sounds good
15:36:42 <rbyers> Topic: Issue with compatibility mouse events and inconsistency with mouse pointerevent: https://github.com/w3c/pointerevents/issues/35
15:37:00 <dtapuska> ACTION: NZ/RB to issue a pull request for pointer ids to be the same inside  top level browsing context
15:37:00 <trackbot> Error finding 'NZ/RB'. You can review and register nicknames at <http://www.w3.org/2012/pointerevents/track/users>.
15:37:43 <dtapuska> RB: We want a consistent enter leave sequence for compatibility mouse events
15:38:00 <dtapuska> ... mouse events have a consistent sequence
15:38:08 <dtapuska> ... pointer events have a consistent sequence
15:38:38 <dtapuska> ... but spec says there is a 1:1 mapping. But you can't have all 3. They are contradictory.
15:39:11 <dtapuska> NZ: Are we sacraficing mouse event conistency
15:39:26 <dtapuska> RB: Is there a bug tracking edge that this isn't consistent here
15:39:33 <patrick_h_lauke> because each primary pointer fires compat mouse events, so if you have multiple input modalities (e.g. mouse and touch) you get crossed sequences
15:39:58 <dtapuska> TD: Not aware of a bug; but will look into it. Seem to recall I did put in a bug. Can just flip a bit on the bug to make it public.
15:40:24 <dtapuska> RB: The mouse event sequence isn't consistent with the UI Event spec
15:41:10 <dtapuska> NZ: Why do we want to match pointer events with mouse events. If this is a compatability;  we want to make sure the page has a consistent behaviour for the page since they are only using mouse events
15:41:30 <dtapuska> JR: We aren't seeing site compatibility.
15:41:53 <dtapuska> ... Fairly obscure;  multi modal touch scenario
15:42:22 <dtapuska> ... way it is defined today is primary because of the easier implementation
15:43:02 <dtapuska> MA: when you have multiple input. If we just break the 1:1 mapping; try to match the last movement on the screen that should work
15:43:28 <dtapuska> MA: site will only see the last one
15:44:08 <dtapuska> JR: Make mouse enter/exit difficult.  Originally implement a model when only one was going to be a primary pointer. Scenario where this is problematic
15:44:33 <dtapuska> ... going to try to dig up old messages on it. We made them all primary
15:45:36 <patrick_h_lauke> PL: my take would be: current way that compat mouse events are fired is possibly "good enough". it's not aiming to also provide perfectly consistent mouse sequences that are self contained in multi-input scenarios
15:45:36 <shepazu> q+
15:45:41 <dtapuska> PL: Once you start adding mutli modal input on pages that are only designed for a single point input that gets complicated
15:46:06 <dtapuska> ... We might just add a note to describe this behaviour because it likely doesn't cause a real interop issue
15:46:43 <dtapuska> RB: Edge might say two things get a hover case where
15:47:24 <dtapuska> ... If you have one point down and then add another and move it.
15:47:28 <shepazu> q-
15:47:32 <shepazu> +1
15:47:37 <patrick_h_lauke> +1
15:47:44 <shepazu> q+
15:48:00 <dtapuska> ... Can we come up with some spec language to try to write some interop language around this?
15:48:29 <dtapuska> JR: sure; you are free to make suggestions and we can look at it
15:49:29 <patrick_h_lauke> PL: i can see the scenario now...move mouse over a hover menu, menu opens, and then you use finger to tap on something else. should the mouse unhover? (though arguably you'd then script this yourself in your own JS to close the menu)
15:49:37 <dtapuska> DF: I like a consistent model. Multi modal isn't a big deal. As we merge more modalities we will see more mouse, touch, gesture interactions
15:49:46 <dtapuska> JR: We are just talking about legacy mouse events
15:50:15 <dtapuska> JR: If you are building pages that are multi modal you should use pointer events
15:50:37 <dtapuska> DF:  We should note it as being an issue.
15:51:07 <dtapuska> SG: We have this potential issue with legacy issues. But it really isn't an issue with multi-modal.
15:51:15 <dtapuska> DF: Ya I guess that is right
15:51:48 <dtapuska> RB: I don't like the PointerEvents spec indicating how UIEvents spec should be interpreted.
15:51:59 <dtapuska> ... Especially when the are in contrast.
15:52:33 <dtapuska> ... Perhaps we should just leave the pointer events spec to define mouse down, mouse up. And leave it up to the UI Events spec about mouse enter/leave
15:52:49 <dtapuska> JR: I didn't think this was that complicated
15:53:15 <dtapuska> RB: Remove entire step for and just refer to the UI Events spec for generation of mouse enter/leave
15:53:40 <dtapuska> PL: Can we add a issue for this to clarify the wording and discuss it there
15:53:53 <dtapuska> RB: We can certainly do a pull request
15:53:59 <dtapuska> JR: Sounds good
15:54:03 <patrick_h_lauke> RESOLUTION: rick to make a PR
15:54:38 <dtapuska> PL: We are running a bit short on time
15:54:47 <circ-user-eEWFe> NZ:We have added pointer event support in Chrome behind the flag. Right now it’s available in Canary. Pointer event web platform test are mostly passing. Particularly, those that are not passing are in touch implicit capturing and not hit-testing after a pointer is captured for touch.
15:54:50 <dtapuska> Topic: Implementation Status
15:55:53 <dtapuska> NZ: stylus leaving digitizer issue; one of the test that we are failing
15:56:14 <dtapuska> RB: Basically we are feature complete. Few issues. -Behind a flag developers can enable.
15:56:24 <dtapuska> ... Few open design questions; implicit capture is the key one
15:56:32 <dtapuska> .. moving our focus to interoperability
15:56:52 <dtapuska> MB: mozilla is here
15:57:10 <dtapuska> MB: some new folks starting to work on the pointer events stuff in gecko
15:57:26 <dtapuska> MB: should have resources to complete implementation to ship
15:57:49 <dtapuska> DF: Are we seeing more developer uptake of pointer events
15:58:04 <dtapuska> MA: done some data analysis on http archive
15:58:16 <mustaq> https://docs.google.com/spreadsheets/d/1e3prmHeuGT5fS-VYB79IR1GO5pqqppvydXPHdkAAaGo/edit#gid=1229525811
15:58:21 <dtapuska> MA: number of hits of pointer events are dropping
15:59:14 <jossi> jossi has joined #pointerevents
15:59:17 <dtapuska> MA: number of hits per million is dropping.
15:59:36 <dtapuska> PL: it includes usage inside common libraries
15:59:46 <dtapuska> RB: It is basically a grep
16:00:20 <patrick_h_lauke> purely anecdotally, all developers which i speak to (rant to) about PE actually see them as very positive...and can't wait for them to be more commonly available in more than just IE/Edge
16:00:24 <dtapuska> SC: will answer this on the jquery size;  we are going to require pointer events in 113.
16:00:53 <dtapuska> SC: we will use PEP unless you have them natively
16:01:24 <jossi> @mustaq - can you drop the link again? I wasn't in IRC
16:01:39 <dtapuska> jossi: https://docs.google.com/spreadsheets/d/1e3prmHeuGT5fS-VYB79IR1GO5pqqppvydXPHdkAAaGo/edit#gid=1229525811
16:02:02 <dtapuska> RB: We have a backlog to get through
16:02:21 <dtapuska> DF: Weekly for a few weeks seems ok; and then moving to more infequently
16:02:44 <dtapuska> PL: Patrick is double booked; for another W3C call
16:03:09 <dtapuska> RB: A different day might work for us; any earlier probably won't work for people on the west coast
16:03:31 <dtapuska> PL: Move to a need to basis
16:04:33 <dtapuska> RB: When one browser is only implementing it isn't very attractive
16:04:49 <dtapuska> ... but when 3/4 browsers are developers going to shift to it
16:05:10 <scott_gonzalez> https://webkit.org/blog/6131/updating-our-prefixing-policy/
16:05:16 <dtapuska> JR: Just heard how webkit prefixes are being changed
16:05:16 <patrick_h_lauke> JR: mentions about webkit prefixes vs webkit now moving to unprefixed behind flags
16:05:40 <patrick_h_lauke> (motion to buy jacob a new mic :) )
16:05:59 <dtapuska> JR: there are plenty of APIs that exist that aren't in all browsers
16:06:40 <dtapuska> PL: Calling the meeting
16:07:02 <dtapuska> SG: do we know when the hack-athon is going to be
16:07:11 <dtapuska> RB: Can we discuss on the list
16:07:21 <dtapuska> PL: We will put it on the agenda for next week
16:07:46 <patrick_h_lauke> rrsagent, generate minutes
16:07:46 <RRSAgent> I have made the request to generate http://www.w3.org/2016/04/26-pointerevents-minutes.html patrick_h_lauke
16:07:59 <patrick_h_lauke> (like a pro)
16:08:37 <patrick_h_lauke> is there a specific command to officially end meetings/recording? or did the above do the trick?
16:10:14 <patrick_h_lauke> rrsagent, bye
16:11:35 <patrick_h_lauke> rrsagent, make logs world-visible
16:13:02 <patrick_h_lauke> rrsagent, bye
16:13:02 <RRSAgent> I see 2 open action items saved in http://www.w3.org/2016/04/26-pointerevents-actions.rdf :
16:13:02 <RRSAgent> ACTION: RB to create an issue with relevant people to discuss it there. [1]
16:13:02 <RRSAgent>   recorded in http://www.w3.org/2016/04/26-pointerevents-irc#T15-27-26
16:13:02 <RRSAgent> ACTION: NZ/RB to issue a pull request for pointer ids to be the same inside  top level browsing context [2]
16:13:02 <RRSAgent>   recorded in http://www.w3.org/2016/04/26-pointerevents-irc#T15-37-00