14:42:41 <RRSAgent> RRSAgent has joined #pointerevents
14:42:41 <RRSAgent> logging to http://www.w3.org/2016/07/06-pointerevents-irc
14:42:53 <patrick_h_lauke> Chair: patrick_h_lauke
14:45:16 <patrick_h_lauke> Meeting: Pointer Events W
14:45:30 <patrick_h_lauke> Meeting: Pointer Events Working Group
15:02:10 <teddink> teddink has joined #pointerevents
15:02:13 <dtapuska> dtapuska has joined #pointerevents
15:02:45 <dtapuska> present +dtapuska
15:02:52 <rbyers> present+ Rick_Byers
15:03:02 <patrick_h_lauke> present +patrick_h_lauke
15:03:13 <dtapuska> scribe: dtapuska
15:03:20 <teddink> present+ teddink
15:04:00 <patrick_h_lauke> TOPIC: https://github.com/w3c/pointerevents/pull/76
15:04:50 <NavidZ> present+ NavidZ
15:04:54 <dtapuska> NZ: ted seemed to be looking at it and talking to the team
15:05:30 <scott_gonzalez> present+ Scott_Gonzalez
15:05:32 <dtapuska> RB: This is a subtle enough space where we have some implementation differences
15:05:35 <shepazu> present+ shepazu
15:06:05 <dtapuska> TD: The PR as it stands today is a little bit different then Edge behaves
15:06:16 <dtapuska> ... we don't send lost pointer capture until the next event comes in
15:06:38 <dtapuska> ... there is a synthentic event that we should be suppressing that causes lost pointer capture to occur early
15:06:59 <dtapuska> ... if you don't move the mouse and wait a few seconds you will get a lost pointer capture
15:07:06 <dtapuska> ... but we consider that a bug
15:07:43 <dtapuska> ... on the got pointer capture side; we only send got pointer capture when set pointer capture is called as a result of pointer down
15:07:59 <dtapuska> ... we did that way back when for interoperability reasons
15:08:15 <dtapuska> ... unclear whether this is still needed or not.
15:08:37 <dtapuska> ... still in the midst of doing some of that investigation
15:09:10 <dtapuska> ... Ricks point is accurate to get the spec closer to the way chrome and edge are currently doing it... then we can discuss in person the subtle differences
15:09:21 <dtapuska> ... haven't looked at what chrome does in canary
15:09:45 <dtapuska> NZ: chrome follows the spec. We delay the got and lost pointer capture until the next event.
15:09:55 <dtapuska> RB: And we don't really like that in terms of the developer
15:10:02 <dtapuska> ... it is hard to reason about
15:10:35 <dtapuska> NZ: Right and then we thought about doing the pointer down hack Edge has. But then we really want to send it right away as soon as we can.
15:10:54 <dtapuska> ... And then aren't really delayed in Edge because of the synthetic event that fires
15:11:39 <dtapuska> RB: I'd rather spec something that is coherient/rational. and continue iterating on it post ship
15:12:05 <dtapuska> NZ: Right now chrome does what the current spec says; but we can change Chrome to match what this PR says.
15:12:54 <dtapuska> RB: I think we will have a set of outstanding issues and we either match the spec (and not edge); or match against a pull request
15:13:24 <dtapuska> NZ: We probably should resolve this PR as Mozilla was looking at this too; whether they should get a synthetic event..
15:13:55 <dtapuska> RB: its a step in the right direction to land something in the spec
15:14:10 <dtapuska> .. what do you think ted?
15:14:44 <dtapuska> TD: I think I could get behind it; and it is fine for a div that calls set pointer capture; but when something outside of the normal pipeline does it
15:15:21 <dtapuska> RB: Can we agree to land something along these lines and then we can match chrome to this spec. And then file a PR that indicates Edge doesn't match the spec
15:15:50 <dtapuska> PL: Should we add a highlight in the spec that something may change here?
15:16:14 <dtapuska> RB: That depends on how we do that.... some specs do it inline; some don't.
15:16:24 <dtapuska> ... do we track them inline or use github issues
15:16:45 <dtapuska> ... I'd prefer to use github because it can confused the reader.
15:16:52 <dtapuska> PL: git hub seems fine for me
15:17:12 <dtapuska> TD: I agree as well. It is subtle things
15:17:15 <patrick_h_lauke> RESOLUTION: land PR (in some form), track potential issues/compat worries separately in github until we have more data
15:17:30 <shepazu> q+
15:18:22 <dtapuska> DF: First public working draft publishing; do we need issues resolved before hand? Or can we publish the spec as is?
15:18:31 <dtapuska> RB: I'm comfortable with that
15:18:48 <dtapuska> PL: So that goes FPWD
15:19:09 <dtapuska> ... do I need to write some pseudo marketing blurb?
15:19:52 <dtapuska> DF: w3c usually does that; but if you guys want to write blog posts about it. Happy to work with you on that if you guys want to.
15:20:10 <scott_gonzalez> s/does that/doesn't do that/
15:20:20 <dtapuska> ... we should write a blog post about this spec for the w3c blog to indicate how this spec is great
15:21:12 <patrick_h_lauke> TOPIC: Removed "pen contact" condition on button/buttons
15:21:17 <patrick_h_lauke> https://github.com/w3c/pointerevents/pull/96
15:22:00 <dtapuska> NZ: On this I had a question for ted on his last comment. I didn't understand the css state
15:22:02 <patrick_h_lauke> oh, and i just realised that was actually the topic for Mustaq who's not here sorry
15:22:19 <dtapuska> TD: was that 96 or 93?
15:22:40 <patrick_h_lauke> TOPIC: Clarify click event firing for chorded buttons
15:22:46 <patrick_h_lauke> https://github.com/w3c/pointerevents/issues/93
15:23:14 <dtapuska> NZ: So my question is related to this one.. 93
15:23:40 <dtapuska> TD: Ya I think I have some questions for dev based on the response I got back..
15:24:19 <dtapuska> ... he saw an active css class applied
15:24:58 <dtapuska> NZ: So going back to the UIEvents spec; for every button primary button we to fire a click event
15:26:05 <dtapuska> ... and then we discussed about the barrel button and clicking the pen.  We ciould to suppress the click event
15:26:43 <dtapuska> ... maybe we should fire a click for every mousedown and mouseup; but chrome fires a click for every button event not primary
15:27:26 <dtapuska> RB: Ya we shouldn't worry what chrome does; we have a separate bug for that. This is a really corner case. If someone is doing something with corded buttons they probably aren't listening to click events
15:27:39 <dtapuska> ... Perhaps we should spec what edge is doing
15:28:01 <dtapuska> NZ: If you release a button while the primary button is down it will cancel the click.
15:28:44 <dtapuska> RB: Perhaps we should get the UI Events spec to updated if any mouse button goes down while one is down perhaps click doesn't fire
15:28:59 <dtapuska> NZ: That gets complicated if we introduce the auxclick behaviour.
15:29:35 <teddink_> teddink_ has joined #pointerevents
15:29:49 <dtapuska> NZ: What is the intent of the user while they have a primary button down
15:31:05 <dtapuska> RB: If I lift the release the barrel button after I lift the pen off the screen I don't get a click
15:31:16 <dtapuska> ... but if it is still on the screen I do get a click
15:31:29 <dtapuska> TD:  Ya I don't know
15:31:41 <dtapuska> RB: Should we just file a spec behaviour or UIEvents?
15:31:56 <dtapuska> ... I agree getting it intertwined can be confusing
15:32:06 <dtapuska> ... I think this is orthogonal to pointer events
15:32:19 <dtapuska> TD: So test 1 chrome would work like edge
15:32:42 <dtapuska> ... But for test 2 chrome would send a click for the last pointer up for button 0
15:32:51 <patrick_h_lauke> RESOLUTION: Rick (?) to file bug on UIEvents spec to ask for clarification, as it's orthogonal to pointer events; Chrome to fix its current bug (test 1)
15:33:08 <dtapuska> TD: I think that makes sense; and I'll get a bug open for edge
15:33:21 <dtapuska> RB: this is minor
15:33:40 <dtapuska> TD: Ya I don't think corded buttons actually really get used
15:33:51 <patrick_h_lauke> TOPIC: setPointerCapture should say something about iframes
15:33:56 <patrick_h_lauke> https://github.com/w3c/pointerevents/issues/16
15:34:22 <dtapuska> RB: So the behaviour we are doing in Chrome matches UIEvents.
15:34:42 <dtapuska> RB: Add a note that any change in other buttons is irrelevant
15:36:01 <dtapuska> RB: Ya I think this is subtle; I don't think it blocks shipping; can save this for a F2F
15:36:08 <patrick_h_lauke> RESOLUTION: pretty subtle scenario, but not blocking v2 - more discussion on github if needed. nice for consistency perspective, but not a major attack vector concern
15:36:37 <dtapuska> TD: Ya our security team feels the way; there is potential something but not high priority
15:38:26 <patrick_h_lauke> TOPIC: Should a captured pointer send boundary events by default?
15:38:33 <patrick_h_lauke> https://github.com/w3c/pointerevents/issues/61
15:38:39 <patrick_h_lauke> linked to https://github.com/w3c/pointerevents/issues/39 and  https://github.com/w3c/pointerevents/issues/8
15:39:07 <dtapuska> PL: This is the big topic that we've been pushing around.. I think ted was going to circle back
15:39:50 <dtapuska> TD: Ya it isn't that easy we are still trying to figure out what sites to understand then whether if we change something whether we would break them
15:40:34 <dtapuska> ... as well as mining the bug database and talking to the dev team; but this is still an ongoing effort. Ya if you could find specific sites it would be great to do that in a couple of weeks
15:41:27 <patrick_h_lauke> RESOLUTION: ongoing work to look at bugs and dev expectations; something to discuss further at F2F; decide if variance is a blocker for shipping in chrome
15:41:30 <dtapuska> RB: We may not decide what the right answer is before we ship. I think we should decide as a group whether some features is reasonable for chrome to ship with a different implementation than edge
15:41:51 <patrick_h_lauke> TOPIC: Outstanding PRs
15:41:55 <patrick_h_lauke> https://github.com/w3c/pointerevents/pulls
15:42:53 <dtapuska> NZ: specifically the last two have been open for a longer time; about hit testing and boundary events
15:43:15 <dtapuska> ... We'd like to do no hit testing when pointer is captured
15:43:50 <dtapuska> RB: We need to have chrome match the spec with these Pull requests
15:44:14 <dtapuska> ... ok to have open pull requests when there are open design concerns
15:44:44 <dtapuska> TD: Ya I think the lost pointer capture; needs to be concerned about the hit testing and the performance of the hit testing
15:45:10 <dtapuska> ... do you have any specific data in terms of how much hit testing costs?
15:45:41 <dtapuska> ... is hit testing costly in chrome that you need to worry about
15:46:31 <dtapuska> RB: There are performance experts that would argue that it is important. And they would block shipping pointer events based on it.
15:47:30 <dtapuska> ... And so we did some comparisons between edge and chrome based on the cost and it was very similar. But then question is how much is expensive and we have different opinions on that
15:48:04 <dtapuska> .... we have 16ms per frame; and if it takes 1% of the frame budget then it is too much.
15:48:13 <shepazu> q+
15:48:49 <dtapuska> ... there are some times that take 100ms for a table with lots and lots of rows; and the code is a big ball of legacy code. So there are concern of making more things dependent on that.
15:49:16 <dtapuska> ... hit testing is part of the Response in RAIL; and no the Animation conformence
15:49:27 <scott_gonzalez> s/no/not/
15:49:42 <dtapuska> TD: Ya our performance team is also concerned about where we spend our time
15:51:15 <dtapuska> RB: We constantly compare web and android; and the user shouldn't notice the difference. They notice all the advantages of the web; but not the performance disadvantages. And so we don't want to introduce dependencies
15:52:16 <dtapuska> RB: This is our biggest open issue. We need a plan on how to ship pointer events in chrome before the end of tpac
15:53:09 <dtapuska> ... the right people will be there. I'd like the working group to be happy to support us shipping pointer events after tpac; with a set of issues.
15:54:05 <dtapuska> DS: There is no hit testing spec. I'm curious if there is some interest in us writing up a spec about hit testing.
15:54:51 <dtapuska> RB: I think there are 1000% things that we do as I think it would be really hard to get concensus on the Hit testing spec
15:55:46 <patrick_h_lauke> +1 to test suite first, rather than spec
15:55:50 <dtapuska> ... I've been marking hit testing interop bugs with a certain key... we already are quite interoperable; but perhaps we should start with a test drive for hit testing. Like 100 tests that work for everyone; and then deal with the edge cases
15:56:09 <rbyers> https://bugs.chromium.org/p/chromium/issues/detail?id=549211
15:56:11 <dtapuska> ... ok we have 95 tests that we all agree on and then define the reasoning behind them
15:57:16 <dtapuska> DG: That is good; anything that improves interop is great. But I think writing down the things that the spec is based on. And if there are disagreements that we record their behaviour. So something descriptive not prescriptive
15:57:27 <dtapuska> s/DG/DS
15:58:15 <dtapuska> DS: Does that seem like something to do?
15:59:36 <dtapuska> RB: I'm not opposed to someone doing it; but I think to do it well it would take many man years. We could spend a lot of effort; but little benefit. Some benefit but in terms of making web developers lives better perhaps not
15:59:53 <dtapuska> DS: So going back to a test suite is that something useful?
16:00:07 <dtapuska> RB: It is only useful if multiple vendors agree to run them
16:00:26 <dtapuska> ... this is a dicussion to have a tpac; there is a session on interop
16:00:48 <dtapuska> DS: Ya I'll try to attend that; and bring up hit testing
16:01:13 <dtapuska> ... I agree the cost could be high; but we could see what benefits of it are.
16:02:07 <dtapuska> RB: And if anyone has a set of bugs that are interop between vendors it would be good to catalog them.
16:02:42 <dtapuska> ... or if how it is to design a new engine. like is it difficult for servo
16:03:33 <dtapuska> DS: I'll bring it up at tpac and if there are more eyes involved then optimizations might come up...
16:04:48 <dtapuska> PL: Only other point implementation status; and we are over time; so we will call it
16:05:06 <dtapuska> PL: same time next week. See you then
16:05:37 <patrick_h_lauke> rrsagent, generate minutes
16:05:37 <RRSAgent> I have made the request to generate http://www.w3.org/2016/07/06-pointerevents-minutes.html patrick_h_lauke
16:05:48 <patrick_h_lauke> rrsagent, set logs world-visible
16:05:57 <patrick_h_lauke> rrsagent, bye
16:05:57 <RRSAgent> I see no action items