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

> On Jan 27, 2016, at 04:34, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> However, there's nothing in the spec that suggests the
>>> UA should automatically ignore any snappoints that go out of bounds,
>>> while there *is* text that suggests an out-of-bounds snappoints is
>>> valid to snap to.  A browser that chose to auto-ignore out-of-bounds
>>> snappoints would be doing something a bit weird, and likely contrary
>>> to user expectations (after all, being friendly to user expectations
>>> is why we wrote that text!).
>> 
>> I agree with the intent of the text as I understand it, but I am not
>> convinced it is effective.
>> 
>> Maybe my wording suggestion was excessively specific, and we can leave
>> more room for maneuver.
>> 
>> However, as currently phrased, your requirement is a tautology, not
>> a requirement. "Must snap to the most appropriate snap point" isn't
>> much more constraining than "Must do the right thing". It's not
>> testable, and no implementation can fail to conform to the spec by
>> ignoring it.
> 
> True. Most of snap-points is just quality-of-implementation, and
> difficult to test.  Can't do much about that.  Demanding isolated
> rigor for particular aspects doesn't make a ton of sense here.

Since this is interactive stuff, it isn't particularly easy to test.
Testing whether the physics of scrolling and snapping feel good and
similar things is definitely something we shouldn't get into, and
leave to quality of implementations.

I think this is different, because this is the kind of difference
that can let an author create content that works fine for them in
their browser, but has unreachable elements in another browser.
And that's not something that makes sense to leave to quality of
implementation anymore than the "must remained snapped to things
that become unreachable" thing we resolved on recently.

>> * If the element with a snap point would be, in terms of direction,
>> within the corridor of defined by the snap viewport as it scrolls,
>> but the element's snap area never actually enters the the snap
>> viewport due to a very large snap padding, is the most appropriate
>> when you're scrolled all the way to the edge, or must it be ignored?
> 
> I don't understand the question. If it never enters the snap viewport,
> how is it in the corridor?

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.

 - Florian

Received on Wednesday, 27 January 2016 16:36:45 UTC