Minutes for PEWG call Wednesday 11 January

Dear all,

minutes from today's PEWG call are here 
https://www.w3.org/2017/01/11-pointerevents-minutes.html and pasted below.

Please send any amendments/etc by next Tuesday.

W3C
- DRAFT -

PEWG

11 Jan 2017

See also: IRC log

Attendees

Present
patrick_h_lauke, teddink, rbyers, mustaq, NavidZ, dtapuska
Regrets
Olli, Pettay
Chair
Patrick H. Lauke
Scribe
patrick_h_lauke
Contents

Topics
"Specify that "click", "dblclick" and "contextmenu" events are 
PointerEvents" https://github.com/w3c/pointerevents/issues/100
(from Rick) The other thing that would be useful I think is to try to 
review the test status
any other issues to address before CR?
Summary of Action Items
Summary of Resolutions
<scribe> Scribe: patrick_h_lauke
currently only person on call :)

<rbyers> we are dialing in now
guessing this will be a fairly short call...

(famous last words)

Patrick: not sure if PLH is going to join us, but I gather he's now the 
new staff contact since Doug left W3C

"Specify that "click", "dblclick" and "contextmenu" events are 
PointerEvents" https://github.com/w3c/pointerevents/issues/100

Rick: open question on Ted for a while. Microsoft has changed click to 
be PE in edge, but Olli raised concerns

I understand Edge made click a pointer event but truncates some of the 
properties that are not PE

Ted: i think you're correct. still trying to get hard confirmation from 
the team

Rick: if you have specific use case/site that relies on that. Olli seems 
to question if it's worth regarding complexity, and there may be 
politics involved as well, but it would be good to see use case/site 
that shows the rationale. not so worried about complexity if it makes sense

I'll just add note to issue

Navid (?): why just click?

Ted: we initially did this to get it working in an internal framework 
challenge. Not sure about which framework, and not sure if it's still 
necessary

Rick: more fundamental question then is to know WHY we'd want click to 
be a pointer event. Click is going to be around forever. Changing it 
from mouse to PE was likely due to fractional coordinates. Having 
fractional coords in the mouse event would guarantee things that break

so i can understand rationale for changing to pointer event

it's more question of "do we need to make click a pointer event". is it 
worth the cost?

dtapuska: adding pointer events to UI events spec?

Rick: do we only fire click for primary? or for all?

Ted: would need to check

mustaq: only primary sends MOUSE compat events, but not sure about click

Patrick: i have vague memory of having tested this, and all fingers 
(even non-primary) fire click

Rick: Ted, worth asking: unless we find pressing use case, maybe 
something we keep as low priority issue, not v2-blocking. then we can 
ask if Edge could undo that change / understand what implications are if 
Edge changed click back to mouse event rather than pointer event

<scribe> ACTION: Ted to check with team, find use case/rationale for 
Edge behavior [recorded in 
http://www.w3.org/2017/01/11-pointerevents-minutes.html#action01]
<trackbot> Created ACTION-156 - Check with team, find use case/rationale 
for edge behavior [on Ted Dinklocker - due 2017-01-18].
Patrick: we talked about click, what about dblclick and contextmenu?

Rick: we should do same for all of them. they're all PE in Edge, right?

<rbyers> Updated issue: 
https://github.com/w3c/pointerevents/issues/100#issuecomment-271912847
Patrick: do we know for a fact they are also PE? I can test and report 
finding on GH issue

(from Rick) The other thing that would be useful I think is to try to 
review the test status

Rick: based on tip of tree, are we failing any tests in blink?

mustaq: (mentions one particular failure)

<mustaq> Navid: chrome is failing pen leave tests.
Rick: high level: currently blink passing all tests. one or two minor 
issues. maybe we can commit to sending summary of remaining failures on 
list in next week? we should have a chrome or blink bug for each failure

<rbyers> ACTION: Navid to send current Chrome test result details to 
public-pointer-events with a chrome or spec bug link for each 
outstanding failure. [recorded in 
http://www.w3.org/2017/01/11-pointerevents-minutes.html#action02]
<trackbot> Created ACTION-157 - Send current chrome test result details 
to public-pointer-events with a chrome or spec bug link for each 
outstanding failure. [on Navid Zolghadr - due 2017-01-18].
Ted: while you're at it create similar action for me for Edge

<scribe> ACTION: Ted to send current Edge test result details to list 
[recorded in 
http://www.w3.org/2017/01/11-pointerevents-minutes.html#action03]
<trackbot> Created ACTION-158 - Send current edge test result details to 
list [on Ted Dinklocker - due 2017-01-18].
Rick: there should already be an outstanding action for you Ted from few 
months ago ;)
... we also got results from stone

<rbyers> ACTION: Ted to send current test results for Edge to 
public-pointer-events with bug links for any outstanding failures. 
[recorded in 
http://www.w3.org/2017/01/11-pointerevents-minutes.html#action04]
<trackbot> Created ACTION-159 - Send current test results for edge to 
public-pointer-events with bug links for any outstanding failures. [on 
Ted Dinklocker - due 2017-01-18].
Patrick: double action on Ted, to show how we REALLY like the results

Rick: stone sent us an email ...

<rbyers> Stone said the following were the only failures on Firefox 
currently:
<rbyers> https://www.irccloud.com/pastebin/TcqvkTre/
Rick: passing most of the tests. If Edge isn't failing any of these 6 
(but suspect Edge may be as these are recent changes) we can go to CR

Mustaq: what about twist, where we fail too?

Rick: we're likely to get these approved and shipped soon, so we should 
wait and see. if that's last thing that keeps us from CR, we can rip 
that out
... and we need to fix respec warnings (must have just been a change in 
respec), so we'll add v2-blocking

Patrick: I'll take that issue

any other issues to address before CR?

<rbyers> Assigned the ReSpec warnings to Patrick: 
https://github.com/w3c/pointerevents/issues/163
Rick: not sure about process, but what happens once we have all blocking 
issues resolved and we're ready to go to CR. what next? Patrick?

Patrick: I'll need to check with PLH

Rick: will PLH let us go to rec if we have ref to WHATWG DOM?

Ted: I thought we had resolved that...

Rick: they're working on adding missing piece to W3C DOM, so we can 
probably wait until then

Ted: we had similar issue in websec (?). whatwg links, while not loved, 
are ok-ish

Rick: it shouldn't be a political mine field

<rbyers> What about: https://github.com/w3c/pointerevents/issues/135
we have this one issue outstanding...

"What is the relationship between setPointerCapture, PointerLock, and 
browser default behaviors?"

The questions in those issues are good, and yes they should be clarified

There are behaviors that are undefined, but critically there are 
differences in behavior between Chrome and Edge which we should address 
before rec

one of those is difference in movement, which i think Edge is fixing?

Ted: correct

Patrick: related https://github.com/w3c/pointerevents/issues/131

"Incorrect movementX/Y in PointerEvents"

Rick: once locked, you have no X/Y coordinates as such as you have 
infinite "field", so movementX/Y are needed

we should check how Edge and Chrome differ

We don't need spec change, need a test and bug in blink

If we were just doing the weird/special case for just mouse, then spec 
would need to change. if we do it consistently for all PE, no need to 
spec change

Patrick: do we need some non-normative note in PE to define how 
PointerLock behaves with PE, or is this something that the PointerLock 
folks should think about?

Mustaq (?): i don't quite agree with the concept as currently 
implemented [sorry, missing some of the detail here]

Rick: [...] if there's a bug between Blink and PointerLock spec 
(relating to movement props returning 0), then we should file a bug 
against that spec

dtapuska: i don't see movementX/Y being cleared on leave (?)

Rick: back to Patrick's question about the need to mention 
relationship/interaction with PointerLock, it's certainly something we 
should look into to decide if/where it needs to be mentioned/clarified

<rbyers> Assigned https://github.com/w3c/pointerevents/issues/135 to Navid
Rick: AOB?

Patrick: not particularly pressing, just find it interesting about 
pointerType:'dial' https://github.com/w3c/pointerevents/issues/152

Rick: question is really one for Microsoft if THEY are going to expose 
this or not

Ted: nothing in the upcoming release, nothing decided yet

<rbyers> https://github.com/w3c/pointerevents/issues/107
"PointerEvents should have fractional coordinates"

Rick: blink and edge have coords as double. maybe it's time to ask DOM 
UI spec to change this

[looking for info on Firefox implementation]

dtapuska: they're "long"

<dtapuska> 
http://searchfox.org/mozilla-central/source/dom/webidl/MouseEvent.webidl
Rick: still, if Edge and Chrome match on this....

let's check webkit on this

<dtapuska> 
https://github.com/WebKit/webkit/blob/master/Source/WebCore/dom/MouseEvent.idl
dtapuska: they're long in webkit

Rick: depending on how UI events spec defines this, e.g. if they say 
that mouse events truncate, we could add and say PE *don't* truncate. 
will file issue on UI events

<rbyers> Historical points: https://github.com/w3c/pointerevents/issues/22
Rick: we have other issues that are important, but not v2-blocking. e.g. 
historical points API

<dtapuska> 
https://github.com/w3c/web-platform-tests/pull/4408#issuecomment-271680588
dtapuska: one discussion on web platform tests

trying to spec to and from element, and i asked how pointer event ends up...

Rick: if we were just matching mouse events, that'd be no issue (just 
where test belongs)

we should have our own tests, not somebody from ui events needing to do 
PE tests on their side

i'll file issue on our repo

Rick: there IS an interop issue today on this, so we should call it 
v2-blocking

mustaq to look into this

https://github.com/w3c/pointerevents/issues/22

Patrick: question if that old issue is now a dupe of historical points API

<rbyers> For fromElement/toElement I've filed 
https://github.com/w3c/pointerevents/issues/167 as v2-blocking
Patrick: ah, we don't have a history API issue, so not a dupe...

<rbyers> What about https://github.com/w3c/pointerevents/issues/161 ?
Rick: sounds like just editorial

https://github.com/w3c/pointerevents/issues/16

"setPointerCapture should say something about iframes"

Rick: we should define that setPointerCapture can fail in sandboxed iframes

but not v2-blocking

if we could add "allow pointer capture" to the html spec...

does pointer lock spec say anything in its spec?

dtapuska: yes, it has phrasing in spec

Rick: should be simple pull request to html spec. we should add it 
quickly before it's relied on

and then we add matching reference in PE spec

i'll file spec issues

we could make it v2-blocking. Ted any hope this can go out to Edge quickly?

Ted: I can have conversation, but not hopeful that it can be done quickly

dtapuska: we can add it to the html spec anyway

Rick: let's not mark as v2-blocking then, it's trivial (for blink to 
implement)

<scribe> ACTION: Patrick to check with PLH about publication process etc 
[recorded in 
http://www.w3.org/2017/01/11-pointerevents-minutes.html#action05]
<trackbot> Created ACTION-160 - Check with plh about publication process 
etc [on Patrick Lauke - due 2017-01-18].
Summary of Action Items

[NEW] ACTION: Navid to send current Chrome test result details to 
public-pointer-events with a chrome or spec bug link for each 
outstanding failure. [recorded in 
http://www.w3.org/2017/01/11-pointerevents-minutes.html#action02]
[NEW] ACTION: Patrick to check with PLH about publication process etc 
[recorded in 
http://www.w3.org/2017/01/11-pointerevents-minutes.html#action05]
[NEW] ACTION: Ted to check with team, find use case/rationale for Edge 
behavior [recorded in 
http://www.w3.org/2017/01/11-pointerevents-minutes.html#action01]
[NEW] ACTION: Ted to send current Edge test result details to list 
[recorded in 
http://www.w3.org/2017/01/11-pointerevents-minutes.html#action03]
[NEW] ACTION: Ted to send current test results for Edge to 
public-pointer-events with bug links for any outstanding failures. 
[recorded in 
http://www.w3.org/2017/01/11-pointerevents-minutes.html#action04]

Summary of Resolutions

[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 Wednesday, 11 January 2017 17:09:56 UTC