[css-scroll-snap] Visibility requirement makes x and y axis snapping dependent

[majido]

I think the current wording of 5.2.1. Scoping Valid Snap Positions to Visible Boxes does not work well when there are visible snap alignments in both axis.

a scroll container cannot be snapped to a snap area if no part of it is within the snapport.

Consider the following case where both snap alignment in x and y axis are valid by current definition. However if UA snaps to both of them in their respective axis the end result will be that neither will be visible which I believe is not the intended outcome of this section.

Should the wording be updated to make it clear that the following snap position is not valid?

Regardless of the wording, I think the more fundamental issue is that each of the alignments is valid on its own axis but their combination is not valid. So to satisfy the visibility goal, the potential alignments on both axis should be considered together.

I am not sure what is the right solution/behavior here. Perhaps it should be left to UAs to decide how to satisfy this requirement. A naive solution will be to find the intended snap candidates and if they don't fit in snapport then drop one. But I suspect an optimal solution will require evaluation of all potential pairs which can be costly and complex.

BTW, I also feel that the fact that this visibility requirement is coupling the snap position selection of x and y axis is somewhat in contrast with rest of the spec where it seems to wants to treat snap positions for each axis independently e.g. section 4.1.1:

snap positions are evaluated independently per axis

[tabatkins]

Hmm, that's a good point.

(Your exact example shouldn't trigger anything, as they're far enough away from the scroll direction that they can't both be alignable and within the target viewport. But you could put them much closer together and get it to trigger.)

@fantasai Thoughts? I think Majid's suggestion that we have an explicit out for "if aligning to both axises would make you hide at least one of the aligning elements, just don't align one of the axises" is a good one.

[majido]

(Your exact example shouldn't trigger anything, as they're far enough away from the scroll direction that they can't both be alignable and within the target viewport. But you could put them much closer together and get it to trigger.)

Probably my diagram is not clear but I was picturing a case where user scroll gesture ends at this situation and we are looking for snap alignment in both axis. If I read the spec correctly in this situation both elements are visible within the snapport and thus valid candidate in their respective axis.

I included the direction arrow to emphasis that user scrolling both horizontally and vertically which is why the logic is looking for snap alignments in both axis. Presumably if the user was only scrolling in one direction the UA may decide to only consider snapping in that axis.

[tabatkins]

All right, we added:

Note: Although ''scroll-snap-type: both'' evaluates [=snap positions=] independently in each axis,
<a href="#choosing">choosing</a> of a [=snap position=] in one axis
may be influenced by [=snap positions=] in the other axis.
For example, snapping in one axis
may push off-screen the [=snap area=] that the other axis would otherwise align to,
making its [=snap position=] invalid and therefore unchooseable.

This work for you?

[majido]

Yes. This allows an implementation to choose snap positions independently in each axis while satisfying the visibility requirement.