- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 10 Nov 2021 16:53:09 +0000
- To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
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