Minute from Pointer Events WG call 28 March 2018

Dear all, minutes from today's call (also available at 
https://www.w3.org/2018/03/28-pointerevents-minutes.html)


Pointer Events WG
28 Mar 2018
Attendees
Present
Navid, Zolghadr, NavidZ_, smaug, patrick_h_lauke, mustaq, ella, plh
Regrets
Chair
Patrick H. Lauke
Scribe
Patrick h. Lauke
Contents
Topics
Summary of Action Items
Summary of Resolutions
<scribe> Scribe: Patrick h. Lauke

<NavidZ_> Present Navid Zolghadr

<NavidZ_> These are the remaining issues

<NavidZ_> 
https://github.com/w3c/pointerevents/issues?page=1&q=is%3Aissue+is%3Aopen+-label%3Afuture-v3&utf8=%E2%9C%93

<NavidZ_> https://github.com/w3c/pointerevents/issues/165

<NavidZ_> https://github.com/w3c/pointerevents/issues/164

#165 patrick will look at

#164 Navid: are our mouse compat events normative?

patrick: it is "optional" but once you support it, you should follow the 
advice
... the issue seems OS/UA specific to me
... if site relies on mouse events, up to browser to decide how to best 
deal with pen/touch/mouse being used simultaneously

<NavidZ_> https://github.com/w3c/pointerevents/issues/236

Navid: decided to close as OS/UA specific

Olli: (explains the bug where cancelling pointerdown prevents mousedown 
but also blocks scrollbar)

Patrick: is scrollbar not part of the browser chrome?

Olli: it's a compat problem

Navid: scrolling is part of the default action/handling? should it be 
called out explicitly that if NOT listed it should still be allowed even 
when cancelled?

Olli: (confirms that cancelling mousedown won't block scrolling)

Navid: are you happy to not modify PE spec

Olli: will investigate what spec this falls under more appropriately, 
like UI Event spec

<NavidZ_> https://github.com/w3c/pointerevents/issues/160

Patrick: it's ... political.

<NavidZ_> https://w3c.github.io/dom/

Philippe: yes, it's political. But if not present in W3C spec, link to 
WHATWG spec

<NavidZ_> https://www.w3.org/TR/dom41/

https://www.w3.org/TR/dom41/#dom-event-composed

if that's the reference, we can point to that one?

PE says "For all pointer events in the table above, composed 
([WHATWG-DOM]) attribute SHOULD be true and detail[DOM-LEVEL-3-EVENTS] 
attribute SHOULD be 0."

so if all we're doing is mention the composed attribute...then we can 
just link to w3c one

Navid: will take this issue to check

Philippe: for inline references, you can keep them the way they are. but 
for normative references, add both the w3c and whatwg

<NavidZ_> https://github.com/w3c/pointerevents/issues/143

Navid: suggest to move to future-v3

<NavidZ_> https://github.com/w3c/pointerevents/issues/139

NAvid: it's not blocking us

Olli: this is more about getting our tests set up better

Navid: adding to future, but hoping to get this automated

<NavidZ_> https://github.com/w3c/pointerevents/issues/126

Patrick: that to me still feels like outside of PE scope

Navid: move to future-v3

or do we want to move to touch events spec

Patrick: move to v3

Olli: agree this is beyond scope

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

Navid: we experimented, but definitely not something for v2

Mustaq: agree. we didn't have any example that failed because of the 
extension/experiment, but it seems too late for this in v2

Navid: (recounts some edge cases of failures using a chrome extension)

Mustaq: let's document this and move to v3

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

Navid: automation is being explored, webdrive-like APIs being added, 
moving forward with pointer action API which is all we need in our set 
of tests. we can keep it open, but add v3 anyway
... hoping to get all automated by end of Q2

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

Patrick: happy to add informative note

Olli: should be spec'd so we can rely on behavior. sounds like edge 
implementation is the right one

Patrick: this is in essence UAs "globbing" multiple gestures into a 
single continuous gesture. as we can't define gestures, we can't 
normatively define things. so keep as note

<mustaq> Next: https://github.com/w3c/pointerevents/issues/106

Navid/Olli: agree

Olli: we shouldn't change/upgrade drag event stuff

Navid: not even try out as experiment? idea is drag being a child of PE 
would then get extra inherited attributes

Olli: but what about weird interactions of capturing a PE, and you then 
try to capture a drag, etc. complex scenarios

Mustaq: (discussed further edge cases)

Navid: let's move to v3

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

Navid: should we do same as for drag event?

(all agree)

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

Navid: olli and i looked at this

Olli: really tricky. i have a patch to make gecko work like edge but not 
chrome, but as chrome doesn't handle setpointercapture in different 
context i'm not even sure if it should or shouldn't. what happens if 
setpointercapture in parent document when iframe passes a pointerId ...

Navid: ... if i mousedown, move to another element, and mouseup, who 
gets the click...
... suggested behavior if pointercapture changes to target, we send it 
to common ancestor

Olli: so chrome and edge will need to change their behavior

Navid: yes. it's most predictable behavior though

Olli: should i land my patch, or wait for change in chrome...

Navid: we had some breakages when we tried changing previously. may have 
to do some back and forth

Olli: may add note about legacy behavior

Patrick: so do we need to change spec?

Olli: not if we go with this.

https://w3c.github.io/spec-releases/milestones/?rec=2018-07-17&noFPWD=true

Philippe/Patrick outline process moving forward for spec

https://github.com/w3c/pointerevents/pull/235/files

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

Patrick: if we could all have a look at the security and privacy 
section, and also the issue above (issue 16) to see about any potential 
security issues there

would like these sorted and in spec before wider review by security folks

<smaug> sorry

Navid: we had our security people looking over an internal issue and 
they had no concerns if iframes have potential to intercept things but 
no real-world cases of it

Patrick: if we could get that issue closed, and the security and privacy 
bit reviewed and added, it would then be good to get WD published early 
next week and sent out for review. If there's any minor further changes, 
can those still be done even after WD publication?

Philippe: yes, as long as they're small and don't invalidate the review 
that's happening

Patrick: in that case, let's work on security things as priority, and 
the other assigned pieces, and publish WD next week

(all agree)

Summary of Action Items
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, 28 March 2018 16:38:07 UTC