[css-overscroll-behavior] Interaction between overscroll-behavior and zooming

[theres-waldo]

The overscroll-behavior spec does not explicilty mention how overscroll-behavior interacts with zooming.

Consider this test page, which has a scrollable div with overscroll-behavior: contain. If you load this page on mobile and zoom in such that the div fills the screen, the behaviour in Firefox is that you cannot scroll to bring all areas of the div into view. Specifically, you can scroll the div itself, i.e. bring new areas into its scrollport, but insofar as zooming made parts of the div's scrollport itself be offscreen, those areas cannot be brought onscreen (because that would constitute scrolling of the enclosing scroll container, which is forbidden by the overscroll-behavior: contain).

It's not clear whether or not this is the intended behaviour. Either way, the spec should be clarified to describe what the intended behaviour is here.

[theres-waldo]

A variation of this question is: if a div with overscroll-behavior: contain (or none) fills the screen (for any reason, doesn't have to involve zooming), are you supposed to have no way of scrolling the enclosing page?

[theres-waldo]

cc'ing spec editors: @bgirard @majido

[theres-waldo]

If you load this page on mobile and zoom in such that the div fills the screen, the behaviour in Firefox is that you cannot scroll to bring all areas of the div into view. Specifically, you can scroll the div itself, i.e. bring new areas into its scrollport, but insofar as zooming made parts of the div's scrollport itself be offscreen, those areas cannot be brought onscreen

This does seem to match Chrome's behaviour as well, so at least there is implementation agreement.

[jonjohnjohnson]

Though I see that the spec doesn't exactly address the issue, I agree with the implementations in gecko/blink, making an author responsible for handling the edge cases with either media queries or possibly intersection observers to enable "scroll chaining" when needed.

I've noticed when using transforms/perspective/sticky/scrollbars for native-like interactions, there are complexities where your best solution is to create a scrolling element outside of the viewport or initial containing block, effectively faking the visual of a "scrollport" as the viewport (example). I'd be concerned about heuristics for zooms or viewport overflowing scrollers, especially after seeing the complexities in blink adding their implicit root scroller, instead of just saying, "hey, no scroll chaining up from this user scrollable element".

[ChumpChief]

The visual viewport (which carries the zoom and is the thing being scrolled in the normal chaining case) is associated with the root scroller. Scroll chaining order doesn't change when zoomed vs. unzoomed, so if the chain is stopped prior to reaching the root (as it is by #bugzilla-body on your test page) it will prevent scrolling regardless of zoom.

The risk of a user manipulating themselves into a stuck state is not new to this feature, e.g. can occur when elements with touch-action: none or ev.preventDefault() are zoomed to cover the screen or inappropriately laid out. This one is at least reversible by the user, since zooming back out should put them into a good state again.

A spec clarification on the visual viewport's participation and location in the chain would probably be good. Maybe in Scroll chaining and boundary default actions, something like "The visual viewport participates in chaining as the document's scrollingElement, both regarding placement in the chain as well as adhering to the chaining rules applied to it."

[majido]

I fully agree with @ChumpChief on this. Basically this is intended behavior since visual viewport is the scroll chaining. I will add a note to this effect if there is no other objection or concern.

[majido]

@theres-waldo I made a change to the spec to clarify the role of viewport in scroll chaining per earlier suggestion. Does this clarify the issue and address your concern?

side note: Since visual viewport is not in csswg yet, I choose to refer to the concept of the viewport in CSSOM. Once visual viewport makes it to CSSOM (which I think is the current plan of the record) we can clarify this even further if necessary.

[theres-waldo]

Yes, thanks for the clarification! I'll close this issue.