Minutes from Pointer Events WG call 10 November 2021

Dear all,

the minutes from today's meeting are at 
https://www.w3.org/2021/11/10-pointerevents-minutes.html and copied below:

PEWG
10 November 2021

Agenda

Attendees
Present
flackr, mustaq, plh, smaug

Chair: Patrick H. Lauke
Scribe Patrick H. Lauke


* Remove should from boundary events note and move to normative must 
https://github.com/w3c/pointerevents/pull/419

* Why is 'touch-events: pan' not a value? 
https://github.com/w3c/pointerevents/issues/420 (new)

* How is pointer event ctor supposed to work when coalescedEvents is 
passed using the PointerEventInit 
https://github.com/w3c/pointerevents/issues/223

* Changing the DOM hierarchy while handling a "pointerenter" event 
produces significantly different results across browsers 
https://github.com/w3c/pointerevents/issues/285

* touch-action:none and overflow:auto 
https://github.com/w3c/pointerevents/issues/319


# Remove should from boundary events note and move to normative must 
https://github.com/w3c/pointerevents/pull/419
pull request in relation to https://github.com/w3c/pointerevents/issues/405

mustaq: [paraphrased] can we be slightly more explicit instead of just 
pointing to UI-Events?

flackr: i could add that browser should treat captured event as if the 
pointer/mouse had been moved to that particular element...

flackr: i can make a change to the PR though if you leave a comment

Patrick: yeah if you want to sort it out in github directly, once we're 
all happy i'll merge it

ACTION: mustaq/flackr/smaug to tweak PR, once ready for merge let 
Patrick know



# Why is 'touch-events: pan' not a value? 
https://github.com/w3c/pointerevents/issues/420 (new)
mustaq: does touch-action:pan not map to touch-action:manipulation ?

Patrick: not quite, as manipulation allows continuous zooming

https://w3c.github.io/pointerevents/#the-touch-action-css-property

Patrick: i think adding touch-action: pan as a shorthand for 
touch-action: pan-x pan-y makes sense, doesn't need any further 
differentiation/explanation

Patrick: the compat spec defines additional touch-action: pinch-zoom but 
we can't touch that here for ... reasons

Oli: concerned about adding this for v3, should it be future?

Patrick: agreed, let's mark this as after v3, as otherwise currently we 
have zero implementation on this

flackr: should we also have something about logical direction values?

Patrick: i believe we have an open issue for that 
https://github.com/w3c/pointerevents/issues/272

flackr: this will make sense once we get support for logical overflow 
directions

Patrick: that issue also marked future, to be considered once v3 is out

ACTION: keep track of issue for future



# How is pointer event ctor supposed to work when coalescedEvents is 
passed using the PointerEventInit 
https://github.com/w3c/pointerevents/issues/223
Patrick: wanted to get a sense if we should just park these issues or if 
they're blockers for v3

Oli: i think chrome implementation did something really weird, in 
firefox it's different weird...

<mustaq> https://w3c.github.io/pointerevents/#coalesced-events

flackr: we expanded spec since then

mustaq: does the wording in the spec currently make it good enough 
(regarding trusted/untrusted events and their initialisation)

<flackr> Existing spec text has "Untrusted events have their coalesced 
events list initialized to the value passed to the constructor"

Oli: need to write some tests...

Oli: but spec might be specific enough now

Oli: we can close the issue now, i'll write tests but that's separate 
from issue

Patrick: i see comments from AnneVK about filing issues against DOM 
though, are they now obsolete?

Oli: ah right, that still needs to be tweak how constructor works

ACTION: Olli to look at remaining constructor work for #223



# Changing the DOM hierarchy while handling a "pointerenter" event 
produces significantly different results across browsers 
https://github.com/w3c/pointerevents/issues/285
mustaq: this is really an issue more about UI Events than anything else, 
but the spec is silent about it too

Patrick: but the ball is fundamentally in their court, so should we 
close this here as it's something that won't just affect pointer events, 
but mouse etc as well

mustaq: Gary mentioned at TPAC about PE hooks, I promised I'd look at 
this for the algorithm

Olli: not sure how algorithm maps to webkit here, but we can review the 
algorithm first and then see if we need to do anything in PE spec

Patrick: is this a blocker for v3? of mark as future?

mustaq: the algorithm has been going for months, so not imminent 
release. so shouldn't block v3

ACTION: mark issue for future, so as not to block v3. mustaq to discuss 
with Gary about algorithm



# touch-action:none and overflow:auto 
https://github.com/w3c/pointerevents/issues/319
[discussion on what the issue is actually about]

flackr: i suspect the gecko behavior is right. we treat scrollable as 
always scrollable regardless of ancestor touch-action, and scrolling one 
can lead to scroll chaining...we can recommend that authors put 
overscroll behaviour to the container with touch-action:none to prevent 
that behavior

Patrick: if we think about this for the next two weeks and at next 
meeting decide what to do (if we need to add something to spec to cover 
these edge cases)

flackr: there are other situations like with position:sticky

ACTION: review #319 for next meeting and see then if we can/should add 
extra wording to spec for this

<flackr> position:sticky refers to the nearest ancestor scrollport 
https://www.w3.org/TR/css-position-3/#valdef-position-sticky where 
scroll port is defined here: 
https://drafts.csswg.org/css-overflow-3/#scroll-container

Patrick: thank you for joining. see you all in 2 weeks' time for next 
meeting

-- 
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, 10 November 2021 16:53:25 UTC