Re: [csswg-drafts] [css-scroll-snap-1] Snapping on both axes allows re-snap after layout to choose inconsistent snap targets (#4651)

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.`

<details><summary>The full IRC log of that discussion</summary>
&lt;heycam> Topic: Snapping on both axes allows re-snap after layout to choose inconsistent snap targets<br>
&lt;heycam> github: https://github.com/w3c/csswg-drafts/issues/4651<br>
&lt;heycam> fantasai: this was an issue raised, there's 2 types of snapping when the document's layout changes<br>
&lt;heycam> ... one type of snapping is find the element you were snapped to, and snap back to it<br>
&lt;heycam> ... the other time is try to find something to snap to, and snap to it<br>
&lt;heycam> ... sometimes you can have multiple elements that happen to snap at the same position<br>
&lt;heycam> ... so when you're in a snapped position, it's not clear which you should re-snap to<br>
&lt;heycam> ... if re-snapping is what you do<br>
&lt;heycam> ... the suggestion was to define which element to re-snap to<br>
&lt;heycam> ... I suggest leaving it to the UA<br>
&lt;heycam> ... but we could say if it's the target element or has focus, we can suggest that<br>
&lt;heycam> ... otherwise I don't have a good idea for a heuristic<br>
&lt;heycam> ... I don't want to disallow UAs to have the freedom to track which is the one currently snapped to<br>
&lt;heycam> astearns: if we're going to have that suggestion, why not specify it?<br>
&lt;heycam> fantasai: we can specify that aspect of the suggestion, but with no target/focus, I don't want to specify that<br>
&lt;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<br>
&lt;heycam> fantasai: [explains an example with a grid with multiple elements in columns, where each column matches the snap position]<br>
&lt;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<br>
&lt;heycam> ... it's like we have an implied "auto" initial value of such a future property<br>
&lt;heycam> ... where auto is UA dependent<br>
&lt;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.<br>
&lt;fantasai> It now has 2 columns<br>
&lt;fantasai> 5 elements we were snapped to are now distributed across 3 columns<br>
&lt;fantasai> which one do we snap to?<br>
&lt;heycam> astearns: proposal is to define beahvior with focused or targetted elements in the set of currently snapped to elements<br>
&lt;heycam> myles: one piece is whether the browser picks an element and follows it, or if the browser should snap to something nearby<br>
&lt;heycam> ... Q2 is if it's picking an element and following it<br>
&lt;heycam> fantasai: spec currently requires that if you're snapped to an element, and layout changes, you follow it<br>
&lt;heycam> ... problem is if there are multiple elements at the current scroll position<br>
&lt;fantasai> Similar question to scroll anchoring -- lots of heurstics involved, don't think we can specify exactly<br>
&lt;heycam> myles: what's the reasoning for following?<br>
&lt;heycam> TabAtkins: if you're snapped to it, and you rotate your phone, you probably want to follow it<br>
&lt;heycam> fantasai: similar situation to scrolling anchoring, but you have more info available<br>
&lt;heycam> heycam: interactions between scroll anchoring and scroll snapping?<br>
&lt;heycam> fantasai: if it's a target, when you scroll to the target, you'll snap to it<br>
&lt;heycam> ... similar to scrollIntoView, focus(), these should all trigger scroll snapping if it's defined on the element<br>
&lt;heycam> heycam: what if one element is focused and the other is the target?<br>
&lt;heycam> fantasai: probably leave it undefined<br>
&lt;heycam> ... though focus seems more important<br>
&lt;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.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4651#issuecomment-577222164 using your GitHub account

Received on Wednesday, 22 January 2020 15:00:04 UTC