See also: IRC log
<patrick_h_lauke> Meeting: Pointer Events Working Group
<scribe> scribe: dtapuska
NZ: ted seemed to be looking at it and talking to the team
RB: This is a subtle enough space where we have some implementation differences
TD: The PR as it stands today is
a little bit different then Edge behaves
... we don't send lost pointer capture until the next event
comes in
... there is a synthentic event that we should be suppressing
that causes lost pointer capture to occur early
... if you don't move the mouse and wait a few seconds you will
get a lost pointer capture
... but we consider that a bug
... on the got pointer capture side; we only send got pointer
capture when set pointer capture is called as a result of
pointer down
... we did that way back when for interoperability
reasons
... unclear whether this is still needed or not.
... still in the midst of doing some of that
investigation
... 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
... haven't looked at what chrome does in canary
NZ: chrome follows the spec. We delay the got and lost pointer capture until the next event.
RB: And we don't really like that
in terms of the developer
... it is hard to reason about
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.
... And then aren't really delayed in Edge because of the
synthetic event that fires
RB: I'd rather spec something that is coherient/rational. and continue iterating on it post ship
NZ: Right now chrome does what the current spec says; but we can change Chrome to match what this PR says.
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
NZ: We probably should resolve this PR as Mozilla was looking at this too; whether they should get a synthetic event..
RB: its a step in the right
direction to land something in the spec
... what do you think ted?
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
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
PL: Should we add a highlight in the spec that something may change here?
RB: That depends on how we do
that.... some specs do it inline; some don't.
... do we track them inline or use github issues
... I'd prefer to use github because it can confused the
reader.
PL: git hub seems fine for me
TD: I agree as well. It is subtle things
RESOLUTION: land PR (in some form), track potential issues/compat worries separately in github until we have more data
DF: First public working draft publishing; do we need issues resolved before hand? Or can we publish the spec as is?
RB: I'm comfortable with that
PL: So that goes FPWD
... do I need to write some pseudo marketing blurb?
DF: w3c usually doesn't do that;
but if you guys want to write blog posts about it. Happy to
work with you on that if you guys want to.
... we should write a blog post about this spec for the w3c
blog to indicate how this spec is great
<patrick_h_lauke> https://github.com/w3c/pointerevents/pull/96
NZ: On this I had a question for ted on his last comment. I didn't understand the css state
<patrick_h_lauke> oh, and i just realised that was actually the topic for Mustaq who's not here sorry
TD: was that 96 or 93?
<patrick_h_lauke> https://github.com/w3c/pointerevents/issues/93
NZ: So my question is related to this one.. 93
TD: Ya I think I have some
questions for dev based on the response I got back..
... he saw an active css class applied
NZ: So going back to the UIEvents
spec; for every button primary button we to fire a click
event
... and then we discussed about the barrel button and clicking
the pen. We ciould to suppress the click event
... maybe we should fire a click for every mousedown and
mouseup; but chrome fires a click for every button event not
primary
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
... Perhaps we should spec what edge is doing
NZ: If you release a button while the primary button is down it will cancel the click.
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
NZ: That gets complicated if we
introduce the auxclick behaviour.
... What is the intent of the user while they have a primary
button down
RB: If I lift the release the
barrel button after I lift the pen off the screen I don't get a
click
... but if it is still on the screen I do get a click
TD: Ya I don't know
RB: Should we just file a spec
behaviour or UIEvents?
... I agree getting it intertwined can be confusing
... I think this is orthogonal to pointer events
TD: So test 1 chrome would work
like edge
... But for test 2 chrome would send a click for the last
pointer up for button 0
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)
TD: I think that makes sense; and I'll get a bug open for edge
RB: this is minor
TD: Ya I don't think corded buttons actually really get used
<patrick_h_lauke> https://github.com/w3c/pointerevents/issues/16
RB: So the behaviour we are doing
in Chrome matches UIEvents.
... Add a note that any change in other buttons is
irrelevant
... Ya I think this is subtle; I don't think it blocks
shipping; can save this for a F2F
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
TD: Ya our security team feels the way; there is potential something but not high priority
<patrick_h_lauke> https://github.com/w3c/pointerevents/issues/61
<patrick_h_lauke> linked to https://github.com/w3c/pointerevents/issues/39 and https://github.com/w3c/pointerevents/issues/8
PL: This is the big topic that we've been pushing around.. I think ted was going to circle back
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
... 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
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
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
<patrick_h_lauke> https://github.com/w3c/pointerevents/pulls
NZ: specifically the last two
have been open for a longer time; about hit testing and
boundary events
... We'd like to do no hit testing when pointer is captured
RB: We need to have chrome match
the spec with these Pull requests
... ok to have open pull requests when there are open design
concerns
TD: Ya I think the lost pointer
capture; needs to be concerned about the hit testing and the
performance of the hit testing
... do you have any specific data in terms of how much hit
testing costs?
... is hit testing costly in chrome that you need to worry
about
RB: There are performance experts
that would argue that it is important. And they would block
shipping pointer events based on it.
... 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
... we have 16ms per frame; and if it takes 1% of the frame
budget then it is too much.
... 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.
... hit testing is part of the Response in RAIL; and not the
Animation conformence
TD: Ya our performance team is also concerned about where we spend our time
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
... This is our biggest open issue. We need a plan on how to
ship pointer events in chrome before the end of tpac
... 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.
DS: There is no hit testing spec. I'm curious if there is some interest in us writing up a spec about hit testing.
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
<patrick_h_lauke> +1 to test suite first, rather than spec
RB: 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
<rbyers> https://bugs.chromium.org/p/chromium/issues/detail?id=549211
RB: ok we have 95 tests that we all agree on and then define the reasoning behind them
DS: 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
... Does that seem like something to do?
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
DS: So going back to a test suite is that something useful?
RB: It is only useful if multiple
vendors agree to run them
... this is a dicussion to have a tpac; there is a session on
interop
DS: Ya I'll try to attend that;
and bring up hit testing
... I agree the cost could be high; but we could see what
benefits of it are.
RB: And if anyone has a set of
bugs that are interop between vendors it would be good to
catalog them.
... or if how it is to design a new engine. like is it
difficult for servo
DS: I'll bring it up at tpac and if there are more eyes involved then optimizations might come up...
PL: Only other point
implementation status; and we are over time; so we will call
it
... same time next week. See you then
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) Succeeded: s/does that/doesn't do that/ Succeeded: s/no/not/ Succeeded: s/DG/DS/ Found Scribe: dtapuska Inferring ScribeNick: dtapuska Present: dtapuska Rick_Byers patrick_h_lauke teddink NavidZ Scott_Gonzalez shepazu Got date from IRC log name: 06 Jul 2016 Guessing minutes URL: http://www.w3.org/2016/07/06-pointerevents-minutes.html People with action items:[End of scribe.perl diagnostic output]