<scribe> Scribe: patrickhlauke
initial hellos, apologies for being a bit slack over the last few months, but we've pulled together to push towards the final stage
PE2 is currently in PR. feedback is already coming in from ACs. 2 positives, no objections/substantive requests for change so far. all things going well, we'll be able to publish by end of calendar year. our group in its current form is chartered until end of December 2018
when PLH will join us, we'll discuss further steps for the working group. rechartering to WG, with possibility of putting the WG dormant until we're confident that we can move forward with substantive work on PE3
NavidZ_ looked at those branches, and they're indeed stale. we can remove
Patrick: wanted to get a feel at high level what the implementation status is, as for the last tests there were still a few failing outstanding items, but they are being worked on
smaug: we still have some issues with pen/touch
other issue is click event handling, which followed the (old) blink behavior which is against the spec as well
NavidZ_ gives example of a page which wasn't using pointer capture, but this was not yet implemented fully so the page relied on the other (non-standard) behavior. we're hoping to implement the behavior from the spec
<NavidZ_> Here is the bug for Chromium regarding targeting of click when pointer capture is active
<NavidZ_> https://bugs.chromium.org/p/chromium/issues/detail?id=689158
Patrick: mentioning recent work on Bootstrap for carousel swipes, and noticing that Firefox was very fickle when setting touch-ACTION: pan-y, but user moves by a few pixels up/down and FX immediately firing pointercancel. do we want/need to say anything about thresholds in the spec? fundamentally it's a user agent issue, which we've shied away from. maybe a non-normative note?
NavidZ_ gives similar example of threshold for browsers starting to handle scroll
Smaug: the situation is also similar to drag'n'drop
<smaug> https://bugzilla.mozilla.org/show_bug.cgi?id=1502010
Patrick: we could avoid having problems with our spec mandating UA behavior (which we've tried to avoid, see also staying away from defining certain gestures etc) by having a "negative" note along lines of "this spec does NOT define how UAs should do this...but here's the issue". possibly an informative note in https://w3c.github.io/pointerevents/#details-of-touch-action-values which already has similar notes. I will file a PR for the group to
discuss. need to also find out from PLH if we're still allowed to make non-normative tweaks of this nature? would assume yes, as following the AC review there may still be some things that need tweaking?
Patrick: also, there's some ReSpec errors...
NavidZ_ looked at the errors, and it brings up question why the Pointer Capture section is marked as non-normative. We'd need to explore this (though may be too late to make normative, in light of publication/above)
NavidZ: status in Chrome implementation
problem with making sense of touch-action on rotated elements, due to compositor
working on Firefox and Edge, but not Chrome. but also, no bugs have been filed against Chrome for real-world sites failing
soon we're going to automate manual tests
Patrick: we don't have anybody here from Microsoft, but from my understanding/conversations, Edge status is essentially stuck at PE Level 1. hopefully when/if we recharter, and get an MS rep, it will be interesting to see if there's desire in Edge to move to parity with Firefox/Chrome
NavidZ_ one of the things that would encourage adoption/work in MS etc would be showing developer desire to use PE
there are some cases like painting apps that can be done (better) with PE, but maybe for next Google.io we could have some more demos of cool things devs can do
Patrick: i think part of the problem is the PE is a cleaner/more sensible way of handling multiple pointer types (not registering mouse, AND touch, AND any proprietary extra stuff - but just a single set of PE, which can then still inside the function differentiate based on pointerType). but beyond that, it doesn't have a major WOW feature
NavidZ_ pointer capture - touch events had implicit capture that couldn't change, but PE lets you explicitly set and unset capture
Smaug: Firefox had a mouse pointer capture API (?) in the past already, which is why we managed to implement it for PE easily
NavidZ_ some nicer/more explicit way of handling RAF, canvas painting, workers, and raw coordinates from pointers etc
wonder how gaming might be affected (positively) by having more low latency / controlled
faster raw events
Patrick: difficult as the spec isn't doing anything "sexy". it's useful/makes sense. e.g. less code forking for different inputs.
big stumbling block has historically been getting developers to use while also telling them to polyfill for iOS, since Apple's silence on this spec meant that potentially devs would have to polyfill indefinitely. made it less of a sell compared to old tried and tested "mouse events plus touch events" (particularly after touch events were extended to allow for Pencil support/distinction).
Patrick: broad overview of what's happening with PEP appearing abandoned. asking what we should do...should/can Google or Mozilla take it over? Should I reach out to jQuery Foundation to see what status is? it's a good reference polyfill, would be shame to see it fall by wayside. some more complex PE Level 2 stuff may not necessarily be polyfillable (e.g. some of the more complex touch-action stuff), but would be good to have at least as a
baseline
NavidZ_: going to check with the Google Maps team (as they used polymer PE which was the original codebase before being shifted out to PEP and taken over by jQuery Foundation)
Patrick: I will reach out jQuery Foundation (Dave Methin (?), Scott Gonzales) to see what their plans are (if any)
(quick break while we wait for PLH who wanted to join us)
PLH: so question is how do we make PE2 part of history? maintenance of PE2, PE3? not in a hurry to push for PE3
https://raw.githack.com/w3c/pointerevents/pe3-charter/charter/pointerevents-charter.html
(PLH gave us a good overview of our options at this point. extending current charter, rechartering, etc)
discussion about obsolete vs superceded
PLH suggests we should do a CFC to mailing list about asking if the group is ok for PE2 to supercede PE1
in future, specify in the spec intro that "this specification supercededs..."
(Travis chats with us about MS commitment/desire to move to adopting more PE2 stuff in Edge. NavidZ_ mentions the PE Extension work https://w3c.github.io/pointerevents/extension.html and Travis suggests this could be submitted to TAG for initial review https://github.com/w3ctag/design-reviews/issues/new)
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/panning/pen/ Succeeded: s/drog/drop/ Present: patrickhlauke smaug NavidZ_ jdai TravisLeithead Found Scribe: patrickhlauke Inferring ScribeNick: patrickhlauke Agenda: https://www.w3.org/wiki/PointerEvents/Meetings#TPAC_2018 WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]