15:52:09 <RRSAgent> RRSAgent has joined #pointerevents
15:52:09 <RRSAgent> logging to https://www.w3.org/2022/01/19-pointerevents-irc
16:01:46 <Patrick_H_Lauke> Meeting: PEWG
16:02:00 <Patrick_H_Lauke> Chair: Patrick H. Lauke
16:02:17 <flackr> flackr has joined #pointerevents
16:02:23 <Patrick_H_Lauke> Agenda: https://www.w3.org/events/meetings/0d3af70c-0054-43dc-9c15-c60c5b9c3f3c/20220119T110000
16:02:36 <Patrick_H_Lauke> Scribe: Patrick H. Lauke
16:02:43 <Patrick_H_Lauke> present+ flackr
16:02:47 <Patrick_H_Lauke> present+ smaug
16:02:52 <Patrick_H_Lauke> present+ Patrick_H_Lauke
16:04:03 <Patrick_H_Lauke> TOPIC: touch-action:none and overflow:auto https://github.com/w3c/pointerevents/issues/319
16:04:09 <Patrick_H_Lauke> Action from last meeting: Rob to create some demos/think some more on best way forward for #319
16:05:44 <Patrick_H_Lauke> Rob: did some work. think it makes sense to make this predictable, regardless of amount of content that leads to overflow or not
16:06:22 <Patrick_H_Lauke> Rob: chrome currently has bug with overflow scroll. once that's fixed, this example can be changed to be predictable
16:06:39 <Patrick_H_Lauke> Olli: sounds reasonable, wonder how to define in spec
16:06:52 <Patrick_H_Lauke> Rob: think it's implied, but we can clear up the overflow spec
16:07:25 <Patrick_H_Lauke> Rob: it has concept of overflow container but doesn't say anything about auto. should just say that overflow:auto is a scroll container
16:07:37 <Patrick_H_Lauke> Olli: wonder if we need to specify something in PE about this too
16:08:05 <Patrick_H_Lauke> https://w3c.github.io/pointerevents/#declaring-candidate-regions-for-direct-manipulation-behaviors
16:08:55 <Patrick_H_Lauke> https://w3c.github.io/pointerevents/#determining-supported-direct-manipulation-behavior
16:10:01 <Patrick_H_Lauke> Rob: "scroll container" is term we should use to clarify things (in second bullet)
16:10:32 <Patrick_H_Lauke> Patrick: can we come up with a sentence, even if rough/high level, in this call for it?
16:11:02 <Patrick_H_Lauke> Rob: it's the "ancestor with the default direct manipulation behaviour" bit that's not well defined
16:11:10 <Patrick_H_Lauke> Olli: should talk about scroll container there
16:12:15 <Patrick_H_Lauke> 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
16:13:32 <Patrick_H_Lauke> Rob: "the root has default direct manipulation behaviour of zoom and scroll, and scroll containers have default direct manipulation behaviour of scroll" (?)
16:13:49 <Patrick_H_Lauke> Rob: suppose we can have definition of default direct manipulation behaviour
16:14:48 <Patrick_H_Lauke> Olli: wonder if it's easier to have a pseudo algorithm here
16:15:06 <Patrick_H_Lauke> Rob: we could also split bullet into two bullets
16:15:59 <Patrick_H_Lauke> Patrick: and then instead of doing a definition for "default direct manipulation" we could just say what we mean
16:16:28 <Patrick_H_Lauke> Rob: zooming may have a closer ancestor in future, but maybe that's something we can worry about in future
16:18:41 <Patrick_H_Lauke> 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.
16:21:13 <Patrick_H_Lauke> 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."
16:21:33 <Patrick_H_Lauke> "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."
16:25:01 <smaug> https://dom.spec.whatwg.org/#document-element vs.  https://dom.spec.whatwg.org/#concept-tree-root
16:28:18 <Patrick_H_Lauke> "document's root element" ?
16:29:35 <Patrick_H_Lauke> "top of the ownerDocument's tree"
16:30:41 <Patrick_H_Lauke> (discussion on further nuance, settling on "document element")
16:30:55 <Patrick_H_Lauke> "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."
16:31:05 <Patrick_H_Lauke> Rob: i wonder what we do with frames
16:31:10 <Patrick_H_Lauke> Olli: and cross-origin iframes
16:31:20 <Patrick_H_Lauke> Olli: we want to say something more complicated
16:32:40 <Patrick_H_Lauke> Rob: i think this is where implementation doesn't match our intent - e.g. if you do zooming on iframe...
16:33:25 <Patrick_H_Lauke> Olli: do we need to say something more about iframes - document element of the topmost browsing context?
16:33:36 <Patrick_H_Lauke> Rob: you shouldn't cross contexts
16:34:46 <Patrick_H_Lauke> 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."
16:36:13 <Patrick_H_Lauke> Patrick: after this call, i'll make PR to split that one bullet into the proposed two bullets above
16:36:52 <Patrick_H_Lauke> Patrick: and that should then close https://github.com/w3c/pointerevents/issues/319 as it would explain what expected behaviour is
16:37:14 <Patrick_H_Lauke> ACTION: Patrick to write PR to split bullet about touch-action and ancestors into two
16:37:38 <Patrick_H_Lauke> TOPIC: Order of pointer events across frames when using pointer capture https://github.com/w3c/pointerevents/issues/355
16:40:38 <Patrick_H_Lauke> Patrick: my naive take would be why does it matter what the order is if it's two frames
16:40:53 <Patrick_H_Lauke> Rob: but they're same origin, so they use the same loop, as if it was in the same document
16:42:20 <flackr> pointerType is determined from the URL so all types should be tested
16:42:20 <flackr> https://github.com/web-platform-tests/wpt/blob/master/pointerevents/pointerevent_pointercapture_in_frame.html?pen#L95
16:42:22 <Patrick_H_Lauke> 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
16:42:43 <Patrick_H_Lauke> Patrick: could we change the test to not use pen ? it's not what's actually being tested...
16:42:55 <Patrick_H_Lauke> Rob: i think the type is dynamic based on url (see above)
16:43:39 <Patrick_H_Lauke> 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
16:44:34 <Patrick_H_Lauke> Olli: we could just comment and close
16:44:45 <Patrick_H_Lauke> ACTION: Olli to comment close issue 355
16:47:18 <Patrick_H_Lauke> 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
16:47:51 <Patrick_H_Lauke> 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
16:48:06 <Patrick_H_Lauke> rrsagent, make logs world-visible
16:48:13 <Patrick_H_Lauke> rrsagent, create minutes
16:48:13 <RRSAgent> I have made the request to generate https://www.w3.org/2022/01/19-pointerevents-minutes.html Patrick_H_Lauke
16:48:19 <Patrick_H_Lauke> rrsagent, make logs world-visible
16:48:31 <Patrick_H_Lauke> rrsagent, bye
16:48:31 <RRSAgent> I see 2 open action items saved in https://www.w3.org/2022/01/19-pointerevents-actions.rdf :
16:48:31 <RRSAgent> ACTION: Patrick to write PR to split bullet about touch-action and ancestors into two [1]
16:48:31 <RRSAgent>   recorded in https://www.w3.org/2022/01/19-pointerevents-irc#T16-37-14
16:48:31 <RRSAgent> ACTION: Olli to comment close issue 355 [2]
16:48:31 <RRSAgent>   recorded in https://www.w3.org/2022/01/19-pointerevents-irc#T16-44-45