Repository navigation
[css-scroll-snap] By design, why does scroll-snap-type disallow per axis strictness? #2728
Description
https://drafts.csswg.org/css-scroll-snap-1/#scroll-snap-type
Before bringing up this issue, I ran my quandary by blink implementors (comment).
I can see how the syntax was designed to infer none in the opposing axis of setting snapping/strictness as well as the ability to set both axes to the same strictness, but a snapping scroller, per spec, doesn't allow per axis strictness.
Even if this may not have a lot of use cases, while playing with the feature on a large scrolling table, I found this limitation undesirable, wishing I could set the strictness of the block axis to mandatory and inline to proximity.
I'm guessing this was a by-product of not creating per axis longhand properties for both logical and physical scroll-snap-type, like we are now dealing with for properties like overflow?
Activity
fantasai commentedon Jun 8, 2018
Related previous discussion was in https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-45 fwiw.
Snapping in one axis and not the other was seen as important, and the main thing people would want to do--snapping in both axes is fairly awkward unless you're in a strictly gridded layout.
We didn't add per-axis strictness because we didn't have a use case that wanted mandatory in one axis and proximity in the other. But we did limit the syntax of the property so that we could add that in the future if there were use cases for it. (Usually keywords are re-orderable, but if we have per-axis strictness then there needs to be a fixed order.)
fantasai commentedon Jun 8, 2018
So I guess the question is, do you have a real-world use case for this? Because if not, we're not going to add it. :)
jonjohnjohnson commentedon Oct 8, 2018
My use case was too obscure for me to have much of a dog in the fight, but thanks for the explanation @fantasai.