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.

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

[css-scroll-snap] By design, why does scroll-snap-type disallow per axis strictness? #2728

Closed
jonjohnjohnson opened this Issue May 31, 2018 · 3 comments

Comments

Projects
None yet
2 participants
@jonjohnjohnson

jonjohnjohnson commented May 31, 2018

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?

@fantasai

This comment has been minimized.

Contributor

fantasai commented 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

This comment has been minimized.

Contributor

fantasai commented 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

This comment has been minimized.

jonjohnjohnson commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment