- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 19 Jan 2022 16:51:27 +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/2022/01/19-pointerevents-minutes.html and copied below: PEWG 19 January 2022 Agenda https://www.w3.org/events/meetings/0d3af70c-0054-43dc-9c15-c60c5b9c3f3c/20220119T110000 Attendees Present flackr, Patrick_H_Lauke, smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke, Patrick_H_Lauke * touch-action:none and overflow:auto https://github.com/w3c/pointerevents/issues/319 * Order of pointer events across frames when using pointer capture https://github.com/w3c/pointerevents/issues/355 # touch-action:none and overflow:auto https://github.com/w3c/pointerevents/issues/319 Action from last meeting: Rob to create some demos/think some more on best way forward for #319 Rob: did some work. think it makes sense to make this predictable, regardless of amount of content that leads to overflow or not Rob: chrome currently has bug with overflow scroll. once that's fixed, this example can be changed to be predictable Olli: sounds reasonable, wonder how to define in spec Rob: think it's implied, but we can clear up the overflow spec Rob: it has concept of overflow container but doesn't say anything about auto. should just say that overflow:auto is a scroll container Olli: wonder if we need to specify something in PE about this too https://w3c.github.io/pointerevents/#declaring-candidate-regions-for-direct-manipulation-behaviors https://w3c.github.io/pointerevents/#determining-supported-direct-manipulation-behavior Rob: "scroll container" is term we should use to clarify things (in second bullet) Patrick: can we come up with a sentence, even if rough/high level, in this call for it? Rob: it's the "ancestor with the default direct manipulation behaviour" bit that's not well defined Olli: should talk about scroll container there Rob: that bullet is confusing because how far you need to go up the ancestors depends on what you're looking for. e.g. for zooming you have to go all the way to root Rob: "the root has default direct manipulation behaviour of zoom and scroll, and scroll containers have default direct manipulation behaviour of scroll" (?) Rob: suppose we can have definition of default direct manipulation behaviour Olli: wonder if it's easier to have a pseudo algorithm here Rob: we could also split bullet into two bullets Patrick: and then instead of doing a definition for "default direct manipulation" we could just say what we mean Rob: zooming may have a closer ancestor in future, but maybe that's something we can worry about in future Patrick: A direct manipulation interaction for panning is supported if it conforms to the touch-action property of each element between the hit tested element and its nearest scroll container ancestor. Patrick: "A direct manipulation interaction for panning is supported if it conforms to the touch-action property of each element between the hit tested element and its nearest inclusive ancestor that is a scroll container." "A direct manipulation interaction for zooming is supported if it conforms to the touch-action property of each element between the hit tested element and the document root." <smaug> https://dom.spec.whatwg.org/#document-element vs. https://dom.spec.whatwg.org/#concept-tree-root "document's root element" ? "top of the ownerDocument's tree" (discussion on further nuance, settling on "document element") "A direct manipulation interaction for zooming is supported if it conforms to the touch-action property of each element between the hit tested element and the document element." Rob: i wonder what we do with frames Olli: and cross-origin iframes Olli: we want to say something more complicated Rob: i think this is where implementation doesn't match our intent - e.g. if you do zooming on iframe... Olli: do we need to say something more about iframes - document element of the topmost browsing context? Rob: you shouldn't cross contexts Patrick: "A direct manipulation interaction for zooming is supported if it conforms to the touch-action property of each element between the hit tested element and the document element of the topmost browsing context." Patrick: after this call, i'll make PR to split that one bullet into the proposed two bullets above Patrick: and that should then close https://github.com/w3c/pointerevents/issues/319 as it would explain what expected behaviour is ACTION: Patrick to write PR to split bullet about touch-action and ancestors into two # Order of pointer events across frames when using pointer capture https://github.com/w3c/pointerevents/issues/355 Patrick: my naive take would be why does it matter what the order is if it's two frames Rob: but they're same origin, so they use the same loop, as if it was in the same document <flackr> pointerType is determined from the URL so all types should be tested <flackr> https://github.com/web-platform-tests/wpt/blob/master/pointerevents/pointerevent_pointercapture_in_frame.html?pen#L95 Olli: it looks like it might just be a bug in chrome. firefox currently has bug with pen type so that's why it fails Patrick: could we change the test to not use pen ? it's not what's actually being tested... Rob: i think the type is dynamic based on url (see above) Olli: based on what's defined in HTML spec, this looks like chrome bug and don't think we need to do anything in PE Olli: we could just comment and close ACTION: Olli to comment close issue 355 Olli: and i commented on https://github.com/w3c/pointerevents/issues/223#issuecomment-1016591840 so once the test is changed that issue can be closed Patrick: yes, we're slowly but surely making progress with getting rid of v3 issues. Once we cleared them we can move towards first steps of publishing this properly -- 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, 19 January 2022 16:51:41 UTC