[css-scroll-snap-1] Why does scroll-snap-align: both snap in each axis independently?

[flackr]

In the css-scroll-snap-1 spec section 4.1.1 it states that for the scroll-snap-axis both:

The scroll container snaps to snap positions in both of its axes independently (potentially snapping to different elements in each axis).

What's the use case for this? I would expect the common case is that the author would expects the UA to snap to both axes of that element if it snaps to that element. If an author wants to snap independently on different axes (e.g. for rows and columns of a table) they can specify snap alignment in a single axis.

Use cases where you'd for sure want alignment in both axes are any sort of 2d selection UI, e.g. a 2d panning map with multiple POI that snaps to a particular POI.

This in particular makes using the snapchanged / snapchanging apis in css-scroll-snap-2 more complicated if you do want to know which element is aligned in both axes.

[flackr]

In fact, the description of the axis values even says that it affects "whether snap positions are evaluated independently per axis, or together as a 2D point." Is it not expected that both should be treated as a 2D point or was the intention to add another value for evaluating it as a 2d point?

[fantasai]

Some prior discussion on this:

• https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-67
• https://www.w3.org/TR/2016/WD-css-scroll-snap-1-20160623/#scroll-snap-type

[flackr]

Some prior discussion on this

Forgive me, i'm having a hard time finding the actual discussion of when you want to snap to a different scroll-snap-align: both elements in the vertical and horizontal axes. The closest I see is https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html where it was discussed that you want to be able to make a scroller snap in one axis but not both.

Can we discuss this? I think it would be really helpful for some common use cases.

If we can't remove independent scroll snapping, could we add a keyword to opt into it? Maybe scroll-snap-type: [element | x | y | inline | block | both] [proximity | mandatory] where element snaps to a single element at a time (implied that it's in both axes).

Or alternately, if we think we can change the default but still want to support explicit independent alignment to scroll-snap-align: both we could add explicitly specifying both axes as meaning snap independently, i.e. scroll-snap-align: both mandatory; selects a single element where scroll-snap-align: x y mandatory snaps to different targets on each axis.

[tabatkins]

I believe the relevant discussion is in one of fantasai's links, https://lists.w3.org/Archives/Public/www-style/2015Jun/0170.html:

The “partial grid” behavior is interesting, but problematic when scrolling: a vertical scroll could yank you sideways to go to nearby snap point. So I’m not sure we want to do this.

This was in support of independent axis snapping, rather than tied-together axis snapping to a single element. We ended up deferring the "cities on a map" snapping behavior that would tie them together, but we didn't rule out adding it back in.

[css-meeting-bot]

The CSS Working Group just discussed [css-scroll-snap-1] Why does scroll-snap-align: both snap in each axis independently?, and agreed to the following:

• RESOLVED: Add TBD keyword to do joined-axis snapping

The full IRC log of that discussion

<TabAtkins> flackr: currently in scroll-snap we treat the axises independently, and allow you to snap to different elements on each axis
<TabAtkins> flackr: there are certainly cases where that's desirable
<TabAtkins> flackr: in most cases you can only snap in one axis anyway
<TabAtkins> flackr: but i think when you ahve an element that can snap in both directions, the intent is usually to snap to the element entirely, or not at all
<TabAtkins> flackr: so i wanted to revisit whether we can at least support this (Tab mentioned this as a possibility in a comment) or if this should even be the default and we add a way to go back to independent-axis snapping
<Rossen> ack fantasai
<TabAtkins> fantasai: we discussed this pretty extensively at one point and concluded we needed both behaviors, but for level 1 we'd only do independent
<TabAtkins> fantasai: but we did recognize we'd want the joined behavior and would need a different behavior. definitely not opposed to adding it
<TabAtkins> Rossen: so adding it in level 2?
<TabAtkins> fantasai:
<TabAtkins> fantasai: yeah
<TabAtkins> flackr: and specifically with a new keyword?
<TabAtkins> fantasai: yes
<TabAtkins> fantasai: we have scroll-snap-2 spec, do we want to go ahead and add it?
<TabAtkins> PROPOSED: Add TBD keyword to do joined-axis snapping
<TabAtkins> fantasai: I suggest keyword 'pair'
<TabAtkins> (flackr suggested 'element' which I also like)
<TabAtkins> RESOLVED: Add TBD keyword to do joined-axis snapping
<fantasai> (it's not an element it's a box :)

[flackr]

So the syntax space where we have both is scroll-snap-type, which is a property of the scroll container. If this is indeed the property where we are adding the pair keyword, there is a question of what to do with elements which only have one scroll-snap-align axis, e.g.

.scroller {
  scroll-snap-type: pair mandatory;
}
.block-and-inline {
  scroll-snap-align: center;
}
.block {
  scroll-snap-align: center none;
}
.inline {
  scroll-snap-align: none center;
}

Do we..

1. Only consider .block-and-inline elements and ignore the others, or
2. Allow snapping to both axes of a .block-and-inline element or snapping to a .block and a .inline element?
3. Something else?

IMO, I think (2) provides a valuable meaning to the .block and .inline in the same way that it works for scroll-snap-type: both, but (1) is simpler to reason about and I'm not sure if there are concrete use cases for for (2).