IRC log of pointerevents on 2016-07-06

Timestamps are in UTC.

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