- From: Majid Valipour via GitHub <sysbot+gh@w3.org>
- Date: Tue, 17 Jan 2017 17:11:23 +0000
- To: public-css-archive@w3.org
majido has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-scroll-snap] Visibility requirement makes x and y axis snapping dependent == I think the current wording of [5.2.1. Scoping Valid Snap Positions to Visible Boxes](https://drafts.csswg.org/css-scroll-snap/#snap-scope) 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](https://drafts.csswg.org/css-scroll-snap/#snap-axis): > snap positions are evaluated independently per axis Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/950 using your GitHub account
Received on Tuesday, 17 January 2017 17:11:29 UTC