-
Notifications
You must be signed in to change notification settings - Fork 652
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 ourterms of serviceand 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
Comments
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 alignableandwithin the target viewport. But you could put them much closer together and get it to trigger.) @fantasaiThoughts? 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. |
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 inbothaxis. Presumably if the user was only scrolling in one direction the UA may decide to only consider snapping in that axis. |
All right, we added:
This work for you? |
Yes. This allows an implementation to choose snap positions independently in each axis while satisfying the visibility requirement. |
I think the current wording of5.2.1. Scoping Valid Snap Positions to Visible Boxesdoes not work well when there are visible snap alignments in both axis.
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 onboth axisshould be consideredtogether.
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. section4.1.1:
The text was updated successfully, but these errors were encountered: