<scribe> Scribe: Patrick h. Lauke
<NavidZ_> Present Navid Zolghadr
<NavidZ_> These are the remaining issues
<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)
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Present: Navid Zolghadr NavidZ_ smaug patrick_h_lauke mustaq ella plh No ScribeNick specified. Guessing ScribeNick: patrick_h_lauke Found Scribe: Patrick h. Lauke WARNING: No "Topic:" lines found. 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: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report 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]