You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.)
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 tomandatory
andinline
toproximity
.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 likeoverflow
?The text was updated successfully, but these errors were encountered: