W3C home > Mailing lists > Public > public-pointer-events@w3.org > July to September 2020

Minutes from Pointer Events WG call 22 July 2020

From: Patrick H. Lauke <redux@splintered.co.uk>
Date: Wed, 22 Jul 2020 17:12:36 +0100
To: public-pointer-events@w3.org
Message-ID: <87c710ae-0339-08eb-bedd-ac2341473f74@splintered.co.uk>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 July 2020 16:12:52 UTC