Draft minutes: 2016 April 26 call

Hi All, (to shamelessly channel ArtB)

draft minutes from the PEWG call on 26 April are available at

https://www.w3.org/2016/04/26-pointerevents-minutes.html

and copied below:

If you have any comments, corrections, etc., please reply to this email 
by 3 May. In the absence of any changes, these minutes will be 
considered approved.

W3C
- DRAFT -

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
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, 26 April 2016 19:25:54 UTC