Repository navigation
[css-scroll-snap-1] Snapping on both axes allows re-snap after layout to choose inconsistent snap targets #4651
Description
According to the spec:
If the scroll container was snapped before the content change and that same snap position still exists (e.g. its associated element was not deleted), the scroll container must be re-snapped to that same snap position after the content change.
The issue is that if there are multiple snap areas aligned on the same axis, then any of those snap areas can be the "associated element" for the same snap position. Therefore the re-snapping after layout could return any one of the snap areas.
Different associated elements for the same snap position should be clarified by the spec.
Note: re-snapping after layout is currently only available on Chrome M80 and it's behind the flag chrome://flags/#enable-experimental-web-platform-features.
Example:
- On mobile, go to https://alsan1998.github.io/grid_cats
- Scroll to snap to the white cat whose coordinate is (1,1).
- Rotate the phone. Re-snapping works well.
- Rotate it back. Scroll snap to the cat (1,2) below.
- Rotate the phone. The scroller may be snapped to an area that wasn't the one in the center of the screen. e.g. re-snapped to (1,1) rather than (1, 2). Repeat steps 2-5 if not see.
Activity
yi-gu commentedon Jan 6, 2020
@majido FYI
fantasai commentedon Jan 16, 2020
I suspect in the multiple elements involved case, the spec should leave it up to the UA which one to choose. I doubt we know for sure what heuristic would be best in these cases, excepting cases where the user has focused an element in which case the focused element should be the one that remains snapped.
So my proposal would be something like
css-meeting-bot commentedon Jan 22, 2020
The CSS Working Group just discussed
Snapping on both axes allows re-snap after layout to choose inconsistent snap targets, and agreed to the following:RESOLVED: Define what happens if you have multiple elements that could satisfy the scroll snapping re-snap situation and there is one that is focused or targeted. Otherwise leave it UA defined.The full IRC log of that discussion
<heycam> Topic: Snapping on both axes allows re-snap after layout to choose inconsistent snap targets<heycam> github: https://github.com//issues/4651
<heycam> fantasai: this was an issue raised, there's 2 types of snapping when the document's layout changes
<heycam> ... one type of snapping is find the element you were snapped to, and snap back to it
<heycam> ... the other time is try to find something to snap to, and snap to it
<heycam> ... sometimes you can have multiple elements that happen to snap at the same position
<heycam> ... so when you're in a snapped position, it's not clear which you should re-snap to
<heycam> ... if re-snapping is what you do
<heycam> ... the suggestion was to define which element to re-snap to
<heycam> ... I suggest leaving it to the UA
<heycam> ... but we could say if it's the target element or has focus, we can suggest that
<heycam> ... otherwise I don't have a good idea for a heuristic
<heycam> ... I don't want to disallow UAs to have the freedom to track which is the one currently snapped to
<heycam> astearns: if we're going to have that suggestion, why not specify it?
<heycam> fantasai: we can specify that aspect of the suggestion, but with no target/focus, I don't want to specify that
<heycam> astearns: I think it would be a good idea if someone would run into this issue if developing in a browser and they end up relying on the UA's choice
<heycam> fantasai: [explains an example with a grid with multiple elements in columns, where each column matches the snap position]
<heycam> florian: leaving it open for now doesn't prevent us from coming up with a heuristic later, or a new property to specify which to re-snap to
<heycam> ... it's like we have an implied "auto" initial value of such a future property
<heycam> ... where auto is UA dependent
<fantasai> Example is a 5-column grid of elements. We scroll down, snapping to each row as we go. The user stops scrolling, resizes the page.
<fantasai> It now has 2 columns
<fantasai> 5 elements we were snapped to are now distributed across 3 columns
<fantasai> which one do we snap to?
<heycam> astearns: proposal is to define beahvior with focused or targetted elements in the set of currently snapped to elements
<heycam> myles: one piece is whether the browser picks an element and follows it, or if the browser should snap to something nearby
<heycam> ... Q2 is if it's picking an element and following it
<heycam> fantasai: spec currently requires that if you're snapped to an element, and layout changes, you follow it
<heycam> ... problem is if there are multiple elements at the current scroll position
<fantasai> Similar question to scroll anchoring -- lots of heurstics involved, don't think we can specify exactly
<heycam> myles: what's the reasoning for following?
<heycam> TabAtkins: if you're snapped to it, and you rotate your phone, you probably want to follow it
<heycam> fantasai: similar situation to scrolling anchoring, but you have more info available
<heycam> heycam: interactions between scroll anchoring and scroll snapping?
<heycam> fantasai: if it's a target, when you scroll to the target, you'll snap to it
<heycam> ... similar to scrollIntoView, focus(), these should all trigger scroll snapping if it's defined on the element
<heycam> heycam: what if one element is focused and the other is the target?
<heycam> fantasai: probably leave it undefined
<heycam> ... though focus seems more important
<heycam> RESOLVED: Define what happens if you have multiple elements that could satisfy the scroll snapping re-snap situation and there is one that is focused or targeted. Otherwise leave it UA defined.
[css-scroll-snap-1] Require re-snapping to the focused element, if mu…
[css-scroll-snap-1] Add example from issue. #4651
fantasai commentedon Sep 17, 2020
Edits checked in as
@yi-gu Is this resolution satisfactory?
@tabatkins i can haz review on edits?
fantasai commentedon Nov 11, 2020
r=@tabatkins