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