<scribe> Scribe: patrick_h_lauke
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
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
<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.
This is scribe.perl Revision of Date 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: patrick_h_lauke smaug mustaq Liviu Found Scribe: patrick_h_lauke Inferring ScribeNick: Patrick_H_Lauke Agenda: https://lists.w3.org/Archives/Public/public-pointer-events/2020JulSep/0018.html 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: consider mustaq olli 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]