See also: IRC log
<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)
<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
<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
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
<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.
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
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
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
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) Found ScribeNick: dtapuska Found Scribe: Dave_Tapuska Present: Navid_Zolghadr Rick_Byers dtapuska patrick_h_lauke shepazu Scott_Gonzalez Mustaq_Ahmed Matt_Brubeck Found Date: 26 Apr 2016 Guessing minutes URL: http://www.w3.org/2016/04/26-pointerevents-minutes.html People with action items: nz rb[End of scribe.perl diagnostic output]