W3C home > Mailing lists > Public > www-style@w3.org > April 2016

Re: [css-scroll-snap][css-snappoints] snapping to unreachable snap points

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 6 Apr 2016 17:55:25 -0400
To: Florian Rivoal <florian@rivoal.net>
Cc: CSS public list <www-style@w3.org>
Message-ID: <570585CD.2000004@inkedblade.net>

https://lists.w3.org/Archives/Public/www-style/2016Jan/0296.html
* should "indirect scrolls" trigger snapping? moving through a document via tab index, scrolling to a target, etc.

     - "yes" appears to be most reasonable answer, which means nothing needs to be done. These are just "explicit" scrolls.



On 01/27/2016 11:36 AM, Florian Rivoal wrote:
>
> Ok, here's an example:
>
> <div id=gallery>
>   <img src=...>
>   ...
>   <img src=...>
>   <img src=...>
> </div>
>
> body {margin:0}
> div {
>    height: 100vh;
>    overflow-y: auto;
>    scroll-snap-point: mandatory;
>    scroll-snap-padding: 10% 0; /* allowing for a semi
>                                   transparent overlay or
>                                   some such */
> }
> img {
>    display: block;
>    max-width: 100%;
>    margin: 20px auto;
>    scroll-snap-align: center;
> }
> img:first-child {
>    scroll-snap-align: start;
> }
> img:last-child {
>    scroll-snap-align: end;
> }
>
> With just the right combination of screen size (large, to make
> the 10% padding large), of a small last image (smaller than
> the 10% padding), and a large penultimate image (so that it
> fills the screen when snapped), depending on how the browser
> snaps, you may be unable to view the last image.
>
> I don't know how you define "the corridor". Is it finite in
> length, or extended infinitely along the direction of the scroll?
> I understand it as the later. So for me, in that example the last
> image is in the corridor, since it would enter the snap viewport
> if you kept scrolling along the same direction. But you can't
> because you hit the edge first, and when you do, due to a large
> snap padding, the image has not entered the snap viewport.
>
> This may have worked fine in the author's environment, but
> different images and different screen size change the game.
> And if we don't make sure that we make this snaps, the user
> will be the one having issues.
>
> Either normatively saying that that last image does not snap
> in this scenario, or allowing enough flexibility for browsers
> to disagree whether it snaps causes this problem to happen.


My intention was to handle this issue in this paragraph:

   # If the most appropriate snap position is unreachable,
   # such that aligning to it would require scrolling the
   # scroll container’s viewport past the edge of its
   # scrollable area, the scroll container must be scrolled
   # as much as possible in each relevant axis toward the
   # desired snap position. This is the used snap position
   # corresponding to that snap position; that is, the UA
   # must “snap” to this position just as it would have if
   # it were the actual specified alignment.

In particular, the second sentence is redefining the effective
snap position for that last element, so a UA *must* treat it
as if it were reachable. However, since this wasn't clear,
we've tweaked the wording slightly to be more explict and
shifted it into the definition of 'scroll-snap-align':
   https://drafts.csswg.org/css-scroll-snap/#unreachable

Let us know if that addresses your concerns.

~fantasai
Received on Wednesday, 6 April 2016 21:55:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:02 UTC