Repository navigation
[css-scroll-snap-1] Snap area trapping behavior of non scrollable elements #4496
Description
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.
Activity
majido commentedon Nov 18, 2019
@tabatkins @fantasai wdyt about this?
fantasai commentedon Jan 16, 2020
I'm not entirely convinced that we should be requiring to clip overflow in order to trap snap points.
Also wondering if
contain: layoutshould 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 @tabatkinscss-meeting-bot commentedon Jan 22, 2020
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 commentedon Apr 23, 2020
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:
So, what I think we should do here is:
in the contain spec, add an additional effect to layout containment about scrolling:
On top of that, we could add a note in css-contain pointing readers to css-scroll-snap for details, for convenience.
in the scroll-snap spec, be specific about the implication for snapping:
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.
8 remaining items
majido commentedon Oct 9, 2020
FWIW when filed this issue the motivation was mostly from implementation perspective.
From Blink perspective the most logical thing for us to do was to update snap element mappings as part of the scroll tree. Because simply adding and removing a scroll container has well-defined hooks which we use to redistribute the snap areas to new scroll containers. Basically treating snapping as a scrolling feature allows us to reuse lots of pre-existing machinery that exists for scrolling.
If any element can capture snap areas then you need to track their add/removal (and possibly maintain a separate tree for them 🤔 ). This is not impossible but I am not sure if it the usecase justifies the implementation cost in Blink. I am no longer have the most up to date information on this feature so take my opinion with a grain of salt. /cc @flackr who may provide better guidance.
css-meeting-bot commentedon Dec 16, 2020
The CSS Working Group just discussed
[css-scroll-snap-1] Snap area trapping behavior of non scrollable elements, and agreed to the following:RESOLVED: Mark this property at-riskThe full IRC log of that discussion
<dael> Topic: [css-scroll-snap-1] Snap area trapping behavior of non scrollable elements<dael> github: https://github.com//issues/4496
<dael> fantasai: Added b/c we had original set up scroll-snap-type where if it's non-inital it traps snaps. If elements inside asking for snap position we ignore. scroll cotnainers have to trap. Added additional behavior for scroll-snap-type so if someone wants to say in this area ignore a snap position they could do so
<dael> fantasai: Seems this is difficult to impl for Blink. Do we want to not have the behavior? Would mean only way to prevent contents from having snap behavior is put in a scroll container
<dael> Rossen_: It's a hack. The hack will work. People will hate the hack. It'll probably end up in css hacks books.
<fantasai> https://github.com//issues/4496#issuecomment-706333521
<dael> Rossen_: Is it really that difficult that we should go to that extent.
<dael> fantasai: Here's comment from impl ^
<dael> fantasai: I'm not aware of any requests for the behavior
<dael> Rossen_: non-Blink impl with opinion?
<dael> smfr: My hunch is it doesn't make sense for non-scrollable things to trap snapping
<dael> fantasai: Within that element we don't track snap position
<dael> Rossen_: Image in a carosel scenario?
<dael> fantasai: No. a section and in that section there's properties setting snap points, you can turn that off. You can say this element ignore the snap positions. We can just not have that behavior and see if someone complaints
<fantasai> s/positions/positions inside/
<dael> Rossen_: In interest of time we can resolve here. If there are no strong arguments for keeping it I'm fine with that
<dael> smfr: Looked at WK and would be easy to impl
<dael> Rossen_: Argument for reverting doesn't seem to be a problem for WK
<dael> Rossen_: What if we keep issue open and when we get to actual impl and get experience I think that's when we come back and decide
<dael> fantasai: Mark at-risk?
<dael> Rossen_: Sensible
<dael> Rossen_: Objections?
<dael> RESOLVED: Mark this property at-risk
fantasai commentedon Dec 16, 2020
@majido Based on comments from WebKit, we ended up just marking this behavior at-risk. That means, if it's not implemented but everything else is, we'll drop the requirement; if it turns out to get implemented, it'll stay in the spec.
scroll-snap-type on non-scrollers traps snap positions