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] Visibility requirement makes x and y axis snapping dependent #950

Closed
majido opened this Issue Jan 17, 2017 · 4 comments

Comments

Projects
None yet
3 participants
@majido

majido commented Jan 17, 2017

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.

2d-snapping-issue

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

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Jan 23, 2017

Member

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.

Member

tabatkins commented Jan 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@majido

majido Jan 25, 2017

(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.

majido commented Jan 25, 2017

(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

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins May 15, 2017

Member

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?

Member

tabatkins commented May 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@majido

majido May 16, 2017

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

majido commented May 16, 2017

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

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