Draft minutes from 6 July 2016 call

Hi All,

draft minutes from the last PEWG call are available at

https://www.w3.org/2016/07/06-pointerevents-minutes.html


and copied below.

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

W3C
- DRAFT -

Pointer Events W

06 Jul 2016

See also: IRC log

Attendees

Present
dtapuska, Rick_Byers, patrick_h_lauke, teddink, NavidZ, Scott_Gonzalez, 
shepazu
Regrets
Chair
patrick_h_lauke
Scribe
dtapuska
Contents

Topics
https://github.com/w3c/pointerevents/pull/76
Removed "pen contact" condition on button/buttons
Clarify click event firing for chorded buttons
setPointerCapture should say something about iframes
Should a captured pointer send boundary events by default?
Outstanding PRs
Summary of Action Items
Summary of Resolutions
<patrick_h_lauke> Meeting: Pointer Events Working Group
<scribe> scribe: dtapuska
https://github.com/w3c/pointerevents/pull/76

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

Removed "pen contact" condition on button/buttons

<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?

Clarify click event firing for chorded buttons

<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

setPointerCapture should say something about iframes

<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

Should a captured pointer send boundary events by default?

<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

Outstanding PRs

<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

Summary of Action Items

Summary of Resolutions

land PR (in some form), track potential issues/compat worries separately 
in github until we have more data
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)
pretty subtle scenario, but not blocking v2 - more discussion on github 
if needed. nice for consistency perspective, but not a major attack 
vector concern
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
[End of minutes]

P
-- 
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 Wednesday, 6 July 2016 16:08:11 UTC