[css-scroll-snap-1] Snap area trapping behavior of non scrollable elements

[majido]

Here is the current spec text related to an ancestor element's trapping behavior for snap areas.

A box captures snap positions if it is a scroll container or has a value other than none for scroll-snap-type. If a box’s nearest snap-position capturing ancestor on its containing block chain is a scroll container with a non-none value for scroll-snap-type, that is the box’s scroll snap container. Otherwise, the box has no scroll snap container, and its snap positions do not trigger snapping.

This allows any regular element which is not a scroll container to trap snap areas.

I tested this on latest Chrome, Safari, Firefox and as far as I can tell no engine does this. Here is a simple test page that shows this. Also I don't think we have a wpt test case for it.

Beside, one can simply achieve the same trapping behavior just by having an element with overflow auto or hidden that does not actually overflow. This works correctly across all engines.

Given that no engine implements this, and the behavior can be achieved without much problem, I suggest we drop this requirement.

I am not really sure what is the motivation behind allowing none scroll container to trap snap areas so maybe I am missing something.

[majido]

@tabatkins @fantasai wdyt about this?

[fantasai]

I'm not entirely convinced that we should be requiring to clip overflow in order to trap snap points.

Also wondering if contain: layout should be invoking this behavior? It's not quite layout, but to the extent that snaps within such an element could interfere with user interactions outside it... //cc @tabatkins

[css-meeting-bot]

The CSS Working Group just discussed Snap area trapping behavior of non scrollable elements, and agreed to the following:

• RESOLVED: No change to scroll-snap-type, but contain:layout must trap snaps.

The full IRC log of that discussion

<heycam> Topic: Snap area trapping behavior of non scrollable elements
<heycam> github: https://github.com//issues/4496
<heycam> fantasai: snapping is on any descendant
<heycam> ... currently spec says if scroll-snap-type is non-none, it normally only applies to the scroll container
<heycam> ... but if you set it on a descendant element, it has the same affect as a scroll container in that snap areas in that box will no longer affect the ancestor scroll container
<heycam> ... Majid points out this hasn't been implemented
<heycam> ... this use case of wanting to trap any of these snap areas is already handeld by setting overflow to auto or hidden
<heycam> ... which means we can remove this
<heycam> fantasai: not convinced on requiriing overflow be set to do this
<heycam> ... but we have the contain property, which likes to contain things, maybe you want contain layout on it -- and you might want contain:layout to trap snap areas
<heycam> TabAtkins: yes it should
<heycam> fantasai: if we're implementing the possibility of trapping snap areas via contain:layout, seems to make sense we maintain the ability to have this independent switch through the scroll-snap-type property
<heycam> astearns: adding a value to scroll-snap-type?
<heycam> TabAtkins: no, it's just any value other than none
<heycam> TabAtkins: the idea would be there's not enough stuff depending on this not trapping
<heycam> heycam: I kidn of find it weird to re-use scroll-snap-type for this different meaning
<heycam> fantasai: you can think of it as scroll-snap-type always captures snaps
<heycam> fantasai: this is already in the spec
<heycam> ... we might want to consider re-tagging this issue against contain, so that we can make contain:layout do this snapturing
<heycam> RESOLVED: No change to scroll-snap-type, but contain:layout must trap snaps.

[frivoal]

I agree with the intent of this resolution, but would like to discuss the precise way to spec it a little further, due to a few principles I think ought to be true:

• the css-contain spec should not need to be (normatively) revised every time another spec adds a new feature. (Adding notes to highlight the effects of other specs is fine)
• the css-contain spec should state the requirements in a way that is generic enough to be always true. It's goal is to create a mode where correctness can be guaranteed, even if some otherwise necessary steps are skipped for the sake of optimizations. If we find classes of effects that ought to be affected by containment, that's worth revising css-contain for, but the revision should capture the whole class.
• other specs which introduce new features ought to clarify how these features interact with containment when that isn't obvious.

So, what I think we should do here is:

• in the contain spec, add an additional effect to layout containment about scrolling:

  • The content, layout, or scroll position of an element with scroll containment or any of its descendants must not affect the scroll position of any box that is not a descendant of containing box for layout containment.

  On top of that, we could add a note in css-contain pointing readers to css-scroll-snap for details, for convenience.

  Note: See "capturing snap positions" in [[css-scroll-snap]] for a specific mechanism affected by this requirement.

• in the scroll-snap spec, be specific about the implication for snapping:

  A box captures snap positions if it is a scroll container, or has a value other than none for scroll-snap-type, or if it has layout containment.

This more generic phrasing in the css-contain spec would not only apply to scroll snap, but also would cover potential future features with similar effects. Let's say we later introduce scroll-locking, where you can somehow declare that the scroll position of one box must continuously be adjusted to track the scroll position of another one, so that when you scroll one, the other follows. The generic phrasing I'm proposing above for css-contain would catch that, while phrasing that is specific to scroll snapping would not.

This would be similar to the second effect of layout containment, about fragmentainers with layout containment trapping the rest fragmented flow. It is stated in generic terms, and leaves it up to spec which would run into that possibility, like css-regions would, to clarify what it would mean for them.