– DRAFT –
PEWG

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