Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[css-scroll-snap-1] Snapping on both axes allows re-snap after layout to choose inconsistent snap targets #4651

Closed
yi-gu opened this issue Jan 6, 2020 · 5 comments
Closed

[css-scroll-snap-1] Snapping on both axes allows re-snap after layout to choose inconsistent snap targets #4651

yi-gu opened this issue Jan 6, 2020 · 5 comments
Labels
Closed Accepted by CSSWG Resolution Commenter Timed Out (Assumed Satisfied) css-scroll-snap-1 Current Work

Comments

@yi-gu
Copy link
Contributor

yi-gu commented Jan 6, 2020

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:

  1. On mobile, go to https://alsan1998.github.io/grid_cats
  2. Scroll to snap to the white cat whose coordinate is (1,1).
  3. Rotate the phone. Re-snapping works well.
  4. Rotate it back. Scroll snap to the cat (1,2) below.
  5. 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.
@yi-gu
Copy link
Contributor Author

yi-gu commented Jan 6, 2020

@majido FYI

@fantasai
Copy link
Collaborator

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

If multiple elements were snapped before the change, which element is re-snapped after the change is up to the UA. However, if any of them have focus, that one must be chosen.

@css-meeting-bot
Copy link
Member

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.

@mozilla-apprentice mozilla-apprentice mentioned this issue Jan 22, 2020
Open
fantasai added a commit that referenced this issue Sep 17, 2020
@fantasai
[css-scroll-snap-1] Require re-snapping to the focused element, if mu…
68ce422 
…ltiple coincide. Otherwise leave to UA. #4651
fantasai added a commit that referenced this issue Sep 17, 2020
@fantasai
[css-scroll-snap-1] Add example from issue. #4651
26fe81a
@fantasai
Copy link
Collaborator

Edits checked in as

If multiple boxes were snapped before and their snap positions no longer coincide, then if one of them is focused or targetted, the scroll container must re-snap to that one and otherwise which one to re-snap to is UA-defined. (The UA may, for example, track which element is snapped as layout shifts align and unalign the snap positions of other elements.)

@yi-gu Is this resolution satisfactory?

@tabatkins i can haz review on edits?

@fantasai
Copy link
Collaborator

r=@tabatkins

@tabatkins tabatkins mentioned this issue Feb 18, 2021
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Closed Accepted by CSSWG Resolution Commenter Timed Out (Assumed Satisfied) css-scroll-snap-1 Current Work
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@fantasai @yi-gu @css-meeting-bot