- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Tue, 3 May 2016 12:25:13 +0100
- To: public-pointer-events@w3.org
(only amendment from draft was the list of attendees present) Pointer Events Working Group Teleconference 26 Apr 2016 See also: IRC log Attendees Present Navid_Zolghadr, Rick_Byers, dtapuska, patrick_h_lauke, shepazu, Scott_Gonzalez, Mustaq_Ahmed, Matt_Brubeck, Jacob Rossi, Ted Dinklocker Regrets Chair Patrick_H_Lauke Scribe Dave_Tapuska Contents Topics publishing FPWD Publishing Pointer Events 2 as FPWD Open issues; pull requests Pointer Id across different iframes: https://github.com/w3c/pointerevents/issues/52 Issue with compatibility mouse events and inconsistency with mouse pointerevent: https://github.com/w3c/pointerevents/issues/35 Implementation Status Summary of Action Items Summary of Resolutions <shepazu> trackbot, start telcon <rbyers> scribenick: dtapuska <rbyers> scribe: Dave_Tapuska <patrick_h_lauke> >> * open issues: priority and scope <patrick_h_lauke> https://github.com/w3c/pointerevents/issues <patrick_h_lauke> https://github.com/w3c/pointerevents/pulls <patrick_h_lauke> >> * testing plan and timeline <patrick_h_lauke> >> * implementation news and plans <patrick_h_lauke> >> * (suggestions?) <patrick_h_lauke> >> * Publishing Pointer Events 2 as FPWD (Call for Consensus) publishing FPWD Publishing Pointer Events 2 as FPWD <teddink> +present teddink shepazu: was muted DS: Put out request; make request to domain lead ... Prepare for publication; shepazu takes a copy and moves to the correct place in /TR; do some coms stuff. ... Send out an email; describe what is different ... Does this draft replace #1 or does it build on it? PL: It builds on it DS: someone coming at it as a blank slate; do they just need to read both? PL: No; it builds on it. Since it completely replaces version 1, we just request a short name <patrick_h_lauke> related: this came out as part of this discussion respec https://github.com/w3c/pointerevents/issues/46 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 ... Keep iterating on it until it goes to CR RB: There is value in doing it when the links made sense; when it was valuable to have a short name 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 RB: Sounds like we should just go through the process; unless anyone objects PL: Sounds alright; should move ahead with FPWD RESOLUTION: We will issue a call for comments on the mailing list DS: 10 day or 2 week call for comments Open issues; pull requests <patrick_h_lauke> (4:04:25 PM) patrick_h_lauke: https://github.com/w3c/pointerevents/issues <patrick_h_lauke> (4:04:25 PM) patrick_h_lauke: https://github.com/w3c/pointerevents/pulls RB: mustaq posted 4 issues to list <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 <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 Pointer Id across different iframes: https://github.com/w3c/pointerevents/issues/52 RB: Question here is do we want to say the id is consistent across iframes ... Is it consistent across windows ... Edge is consistent across window NZ: How does capturing work across iframes; edge has it <rbyers> setPointerCapture should say something about iframes: https://github.com/w3c/pointerevents/issues/16 RB: do you know if capturing across iframes is something developers rely on ... question was asked to Ted; about whether there are metrics of something Edge knows. ... NZ posted a proof of concept attack vector TD: We need to look into that issue to see the actual issue it was posted only yesterday JR: Is it just a case of when pointer is down; you just get the location of the input. What is the security concern 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. ... You could monitor the mouse position without interfering much JR: We did explore the issue back in the day. Would want to see the issue sketched out a little more SC: Is this just a concern pointer capture isn't down NZ: Ads/iframes can interfer the rest of the page when the pointer is down 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 RB: Ads are moving to Sandboxed iframes ... We probably want sandboxed iframes to disallow capture NZ: Sandboxed iframes should only allow capture if the pointer is inside the iframe RB: Is it important for an iframe to capture a pointer that was never targeted to it 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 RB: I'll take to Chrome's security group we have a lot of things to deal with keyboard focus ... Can we all agree on disallowing for sandbox iframes JR: Not sure about that... RB: Sandbox iframes are about cross site scripting JR: Need to explore the security ramifications. We should not explore this in github; use an offline format that isn't publically visible RB: Do we have a method to report issues against Edge that aren't in public domain JR: We don't have the ability to do that RB: We can use chromium bug tracker to track this <scribe> ACTION: RB to create an issue with relevant people to discuss it there. [recorded in http://www.w3.org/2016/04/26-pointerevents-minutes.html#action01] <trackbot> Created ACTION-155 - Create an issue with relevant people to discuss it there. [on Rick Byers - due 2016-05-03]. RB: Need a item in the spec for pointer ids and needs test for it TD: Ok with that we rely on the ids from the OS on this. Edge is just because we rely on Windows 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 PL: The spec should say it is consistent however it is achieve NZ: Is it just iframes are the same or all the windows? ... What about processes? Windows it is free cause it comes from the OS mustaq: What is the scope RB: Should this be top level browsing context ... If you had something across browser windows; it would be possible to make something work in Edge but not Chrome TD: I've built things like that before RB: Doesn't Windows lock the window pointer TD: Need to do some experimentation of what we are doing today with respect to drag events <patrick_h_lauke> http://patrickhlauke.github.io/touch/tracker/multi-touch-tracker-pointer-hud.html RB: those drag and drop events are mouse events so they don't have pointer ids ... Ted said they do fire drag and drop events across windows. And they are HTML5 drag and drop events <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 <patrick_h_lauke> may just be specific to mouse RB: so they don't have a necessary pointer id associated with them TD: We did do this for touch; but we need to do some experimentation to verify there RB: Can we put a pull request to to say pointer ids are associated with the top level browsing context PL: Sounds good Issue with compatibility mouse events and inconsistency with mouse pointerevent: https://github.com/w3c/pointerevents/issues/35 <scribe> ACTION: NZ/RB to issue a pull request for pointer ids to be the same inside top level browsing context [recorded in http://www.w3.org/2016/04/26-pointerevents-minutes.html#action02] <trackbot> Error finding 'NZ/RB'. You can review and register nicknames at <http://www.w3.org/2012/pointerevents/track/users>. RB: We want a consistent enter leave sequence for compatibility mouse events ... mouse events have a consistent sequence ... pointer events have a consistent sequence ... but spec says there is a 1:1 mapping. But you can't have all 3. They are contradictory. NZ: Are we sacraficing mouse event conistency RB: Is there a bug tracking edge that this isn't consistent here <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 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. RB: The mouse event sequence isn't consistent with the UI Event spec 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 JR: We aren't seeing site compatibility. ... Fairly obscure; multi modal touch scenario ... way it is defined today is primary because of the easier implementation 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 ... site will only see the last one 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 ... going to try to dig up old messages on it. We made them all primary <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 PL: Once you start adding mutli modal input on pages that are only designed for a single point input that gets complicated ... We might just add a note to describe this behaviour because it likely doesn't cause a real interop issue RB: Edge might say two things get a hover case where ... If you have one point down and then add another and move it. <shepazu> +1 <patrick_h_lauke> +1 RB: Can we come up with some spec language to try to write some interop language around this? JR: sure; you are free to make suggestions and we can look at it <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) 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 JR: We are just talking about legacy mouse events ... If you are building pages that are multi modal you should use pointer events DF: We should note it as being an issue. SG: We have this potential issue with legacy issues. But it really isn't an issue with multi-modal. DF: Ya I guess that is right RB: I don't like the PointerEvents spec indicating how UIEvents spec should be interpreted. ... Especially when the are in contrast. ... 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 JR: I didn't think this was that complicated RB: Remove entire step for and just refer to the UI Events spec for generation of mouse enter/leave PL: Can we add a issue for this to clarify the wording and discuss it there RB: We can certainly do a pull request JR: Sounds good RESOLUTION: rick to make a PR PL: We are running a bit short on time <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. Implementation Status NZ: stylus leaving digitizer issue; one of the test that we are failing RB: Basically we are feature complete. Few issues. -Behind a flag developers can enable. ... Few open design questions; implicit capture is the key one ... moving our focus to interoperability MB: mozilla is here ... some new folks starting to work on the pointer events stuff in gecko ... should have resources to complete implementation to ship DF: Are we seeing more developer uptake of pointer events MA: done some data analysis on http archive <mustaq> https://docs.google.com/spreadsheets/d/1e3prmHeuGT5fS-VYB79IR1GO5pqqppvydXPHdkAAaGo/edit#gid=1229525811 MA: number of hits of pointer events are dropping ... number of hits per million is dropping. PL: it includes usage inside common libraries RB: It is basically a grep <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 SC: will answer this on the jquery size; we are going to require pointer events in 113. ... we will use PEP unless you have them natively <jossi> @mustaq - can you drop the link again? I wasn't in IRC jossi: https://docs.google.com/spreadsheets/d/1e3prmHeuGT5fS-VYB79IR1GO5pqqppvydXPHdkAAaGo/edit#gid=1229525811 RB: We have a backlog to get through DF: Weekly for a few weeks seems ok; and then moving to more infequently PL: Patrick is double booked; for another W3C call RB: A different day might work for us; any earlier probably won't work for people on the west coast PL: Move to a need to basis RB: When one browser is only implementing it isn't very attractive ... but when 3/4 browsers are developers going to shift to it <scott_gonzalez> https://webkit.org/blog/6131/updating-our-prefixing-policy/ JR: Just heard how webkit prefixes are being changed <patrick_h_lauke> JR: mentions about webkit prefixes vs webkit now moving to unprefixed behind flags <patrick_h_lauke> (motion to buy jacob a new mic ) JR: there are plenty of APIs that exist that aren't in all browsers PL: Calling the meeting SG: do we know when the hack-athon is going to be RB: Can we discuss on the list PL: We will put it on the agenda for next week Summary of Action Items [NEW] ACTION: NZ/RB to issue a pull request for pointer ids to be the same inside top level browsing context [recorded in http://www.w3.org/2016/04/26-pointerevents-minutes.html#action02] [NEW] ACTION: RB to create an issue with relevant people to discuss it there. [recorded in http://www.w3.org/2016/04/26-pointerevents-minutes.html#action01] Summary of Resolutions We will issue a call for comments on the mailing list rick to make a PR [End of minutes] -- 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, 3 May 2016 11:25:22 UTC