- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 22 Jul 2020 17:12:36 +0100
- To: public-pointer-events@w3.org
Dear all, minutes from today's call are at https://www.w3.org/2020/07/22-pointerevents-minutes.html and also copied below: Pointer Events WG 22 Jul 2020 Agenda Attendees Present patrick_h_lauke, smaug, mustaq, Liviu Regrets Chair Patrick H. Lauke Scribe patrick_h_lauke Contents Topics * Changing the DOM hierarchy while handling a "pointerenter" event produces significantly different results across browsers https://github.com/w3c/pointerevents/issues/285 * touch-action and scrolling directional lock https://github.com/w3c/pointerevents/issues/303 * The behavior of `touch-action: none` on <iframe> is unclear https://github.com/w3c/pointerevents/issues/325 <scribe> Scribe: patrick_h_lauke - Changing the DOM hierarchy while handling a "pointerenter" event produces significantly different results across browsers https://github.com/w3c/pointerevents/issues/285 latest status on this was Navid following up with UI spec Mustaq: this is a general event targetting problem? Olli: this seems more specific to PE, defining which order mouseenter and pointerenter should fire Mustaq: defining order after DOM hierarchy is changed? Olli: this needs some more testing first and try to write some more complicated tests Mustaq: there are a few tests there, let me find them <mustaq> I am looking at these: https://wpt.fyi/results/pointerevents?label=experimental&label=master&aligned <mustaq> Yes Olli is correct, we need more tests...only one wpt re pointerenter, only one re compatibility mouse event. Patrick: reading between the lines, it does seem that Chrome takes the UI events spec part literally about not firing any more events once the element is removed. depends on reading/interpretation of what "the sequence MUST NOT be fired" means (i.e. any ongoing sequence, or any follow-up sequence like the leave events) Do you think it's worth reaching out to UI Events spec folks - regardless of PE, even just classic mouse events, what should happen? Olli: we should define the ordering though <mustaq> https://github.com/w3c/pointerevents/issues?q=is%3Aissue+is%3Aclosed+pointerenter Patrick: we did have an early decision about keeping the order of pointer vs mouse events very loose, as it was seen as optional, so UAs "may" do this or not https://w3c.github.io/pointerevents/#compatibility-mapping-with-mouse-events Liviu: wondering why you'd want to capture those events in the parent container (?) I can see why, in case of Chrome, the first 3 events are fired. but then once the element is gone, why would you fire those remaining events? Patrick: it may be a way to "tidy up" behind itself? i.e. the element is gone, so essentially the mouse/pointer has "left" the place it was previously in <scribe> ACTION: Olli will ping Garry on UI Event spec as this issue starts with their thinking on how events should be handled - touch-action and scrolling directional lock https://github.com/w3c/pointerevents/issues/303 Patrick: a lengthy thread, but i think the relevant part is Antoine's last comment (11 Sep 2019) about the two options Mustaq: i think this is the interaction between touch-action and scrolling Patrick: [reading over the thread] I think - at it may be my misreading of it - that this is fundamentally about what to do with touch-action "swallows" certain movements/events, and if that should then still lead to scrolling of any parent element/page Mustaq: [points to the scroll latching/chaining spec https://www.w3.org/TR/css-overscroll-1/] Patrick: so wonder if this is something we can't currently say until that spec is finalised, or make reference to it somehow Maybe it would be best to talk to Navid again, as he may have better overview. Happy to add a little note, or paragraph, in PE that just mentions what should happen. Olli: currently checking/testing in Firefox mobile on this, but need to spend some time on it <scribe> ACTION: Mustaq to sync up with Navid about this issue and come up with some approach - The behavior of `touch-action: none` on <iframe> is unclear https://github.com/w3c/pointerevents/issues/325 <smaug> (as far as I see, all the tests work very similar way in Nightly and Chrome. I don't have i* devices for testing.) Patrick: this is one of those that is probably deceptively simple, but touches on so many aspects like how much control does the iframe container have over what's inside it <smaug> (mobile Nightly and Chrome) Mustaq: and this is similar to previous issue about scroll chaining, and whether or not this crosses the document boundaries if Chrome and WebKit work consistently (even if surprisingly), then perhaps we can just make sure Firefox does the same, and then spec it that way Mustaq: the webkit bug https://bugs.webkit.org/show_bug.cgi?id=213846 mentions pointerevents/ios/touch-action-none-on-iframe.html which seems to be an internal test? Liviu: there is an attachment, and that attachment contains the test it refers to Olli: if webkit and chrome don't prevent scrolling, and that does make sense to me as CSS styling is on per document... Patrick: what if instead on the iframe, it was in a div/parent with touch-ACTION:none. would the iframe bust out of that altogether? [more discussion on what should/shouldn't happen/if it's logical] <mustaq> Updated the issue with this repro copied from the WebKit bug: https://codepen.io/mustaqahmed/pen/yLeZKpP Patrick: I would suggest we get some actual working test cases to play with, and come to some decision. It might be that, for convenience/because of how browsers treat different contexts/origins/documents, we may have to live with this side effect but at least document it <scribe> ACTION: consider this, test with the examples, and decide next time if this needs a spec mention, change in behavior in browsers, or something else Patrick: seeing that we have quite a few issues still left open, and due to (my) relative slackness with pushing things through, suggest we go back to more regular 2-week calls and try to also iterate on things on github in between calls. A few asides - I recently made some tiny updates to MDN page for PE, as that was missing things like compat table and links to actual spec versions etc. that's now all up-to-date for that part https://developer.mozilla.org/en-US/docs/Web/API/Pointer_events#Specifications And I'm currently looking at getting help with making a complete set of diagrams/illustrations for tiltX/tiltY/altitudeAngle/azimuthAngle for the spec. we have tiltX/tiltY, but the newer ones lack diagrams and it would be good to get a consistent set. altitude and azimuth are actually much easier to visualise, while tiltX/tiltY always break my brain, but hoping to have come up with a good plan for those. will keep you posted/send examples once they're done. in meantime, thank you. next meeting on 5 August. Summary of Action Items [NEW] ACTION: consider this, test with the examples, and decide next time if this needs a spec mention, change in behavior in browsers, or something else [NEW] ACTION: Mustaq to sync up with Navid about this issue and come up with some approach [NEW] ACTION: Olli will ping Garry on UI Event spec as this issue starts with their thinking on how events should be handled -- Patrick H. Lauke https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Wednesday, 22 July 2020 16:12:51 UTC