See also: IRC log
<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
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
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
<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].
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Navid (?)/mustaq/ Found Scribe: patrick_h_lauke Inferring ScribeNick: patrick_h_lauke Present: patrick_h_lauke teddink rbyers mustaq NavidZ dtapuska Regrets: Olli Pettay Got date from IRC log name: 11 Jan 2017 Guessing minutes URL: http://www.w3.org/2017/01/11-pointerevents-minutes.html People with action items: navid patrick ted WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]