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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Florian Rivoal-4
On the last teleconf, we discussed what happens when you are snapped to a snap point that becomes unreachable due to some relayout, and concluded that the UA must stay snapped to it.

This discussion naturally continues into the question of how we should handle snapping TO an unreachable snap point (from a reachable one or a non snapped position).

The spec says this (since this has yet to be integrated to css-snappoints, I'm going off the css-scroll-snap spec):

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

I agree with it for the same reasons I agreed to what we resolved in the last teleconf, including the fact that it says MUST. However, I think ambiguous wording makes it ineffective: this clause can be ignored simply by considering any unreachable position as not being "the most appropriate".

I don't think we should leave that up to entirely user agents, because this isn't really a case of some users liking it one way and some another way; authors need write their content/style differently depending on the behavior, since which behavior we choose can make the difference between content being reachable or not.

Proposal for Axis snapping:

* Under mandatory snapping:
  - when the user makes a semantic scroll in a certain direction
  - or when the user makes an inertial scroll in a certain direction which has enough velocity to escape the current snap point
  - or when the user makes an explicit scroll to the very edge of the scroller
then, if there is an unreachable snap point in that direction, then it is "the most appropriate", and the UA must snap to it.

* Under proximity snapping:
  - when the user makes a semantic scroll in a certain direction that scrolls far enough to reach the edge of the scroller
  - or when the user makes an inertial scroll in a certain direction which has enough velocity to reach the edge of the scroller
  - or when the user makes an explicit scroll to the very edge of the scroller
then, if there is an unreachable snap point in that direction, then it is "the most appropriate", and the UA must snap to it.

In either case, if there are multiple unreachable snap points in the same direction, the UA should only snap to the first one.

For point snapping, it seems that the same criteria apply, with the added constrain that the scroller needs to be on at the right position on the other axis.

In another part, the spec also says:

> Since the purpose of scroll snapping is to align content within the viewport for optimal viewing: in all cases, the specified alignment creates a valid snap position only if at least part of the snap area is within the snap viewport.

I think the intent is about when element is not within the snap viewport due to being off to the side. In that case I think it is fine. However, if it is not off to the side, but instead isn't within the snap viewport due to a large scroll-snap-padding in the direction of the scrolling, I think this should not apply (otherwise it defeats the part of the earlier point).

For example, say you have a 1d scroller, with a large  scroll-snap-padding (maybe because it was expressed as a percentage and the screen is larger than expected), and a small element with a (mandatory) snap-point in it, that is close to or at the edge of the scroller. Even if the element is entirely under the snap padding, it should still qualify as "the most appropriate" and snap when you're trying to scroll to the end, rather than be discounted because it is entirely outside of the snap viewport.

  - Florian


Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Sun, Jan 24, 2016 at 4:07 AM, Florian Rivoal <[hidden email]> wrote:
> I agree with it for the same reasons I agreed to what we resolved in the last teleconf, including the fact that it says MUST. However, I think ambiguous wording makes it ineffective: this clause can be ignored simply by considering any unreachable position as not being "the most appropriate".

The spec intentionally doesn't mandate the selection algorithm for
snap points.  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!).

~TJ

Reply | Threaded
Open this post in threaded view
|

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

Florian Rivoal-4

> On Jan 26, 2016, at 04:29, Tab Atkins Jr. <[hidden email]> wrote:
>
> On Sun, Jan 24, 2016 at 4:07 AM, Florian Rivoal <[hidden email]> wrote:
>> I agree with it for the same reasons I agreed to what we resolved in the last teleconf, including the fact that it says MUST. However, I think ambiguous wording makes it ineffective: this clause can be ignored simply by considering any unreachable position as not being "the most appropriate".
>
> The spec intentionally doesn't mandate the selection algorithm for
> snap points.

I think this is absolutely the right thing to do with regards to how
inertial scroll works, how the gravity wells work, how to determine
proximity, how (and whether) to do axis-locked scrolling, etc.

I do think that some edge cases should be mandated, to avoid
divergences that would cause not a difference in look and feel,
but a difference of interoperability. Whether or not something
can be snapped to at all falls on that side, and I think you
agreed, since that's one of the few places in section 7 where
you actually use MUST.

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

I don't expect any browser to auto ignore all out-of-bonds snappoints,
but I do worry that if we leave it too fuzzy, there could be scenarios
where some unreachable snap-points are unsnappable in some browsers,
while being snappable in others, leading to non interoperable behavior,
and unreachable content in some browsers but not others, and authors
not noticing when they use the "wrong" browser to test.

In particular, at least the two following case aren't clear
cut based on how I read the spec, but I think they should be:

* Does it matter how far out an unreachable snap point is
to determine if it "the most appropriate"? Can some unreachable
snap points be so far out that they never are the most appropriate?

* 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?

 - Florian
Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Mon, Jan 25, 2016 at 7:09 PM, Florian Rivoal <[hidden email]> wrote:

>> On Jan 26, 2016, at 04:29, Tab Atkins Jr. <[hidden email]> wrote:
>> On Sun, Jan 24, 2016 at 4:07 AM, Florian Rivoal <[hidden email]> wrote:
>>> I agree with it for the same reasons I agreed to what we resolved in the last teleconf, including the fact that it says MUST. However, I think ambiguous wording makes it ineffective: this clause can be ignored simply by considering any unreachable position as not being "the most appropriate".
>>
>> The spec intentionally doesn't mandate the selection algorithm for
>> snap points.
>
> I think this is absolutely the right thing to do with regards to how
> inertial scroll works, how the gravity wells work, how to determine
> proximity, how (and whether) to do axis-locked scrolling, etc.
>
> I do think that some edge cases should be mandated, to avoid
> divergences that would cause not a difference in look and feel,
> but a difference of interoperability. Whether or not something
> can be snapped to at all falls on that side, and I think you
> agreed, since that's one of the few places in section 7 where
> you actually use MUST.

Yeah, there are a few things that just don't make sense if you don't do them.

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

> I don't expect any browser to auto ignore all out-of-bonds snappoints,
> but I do worry that if we leave it too fuzzy, there could be scenarios
> where some unreachable snap-points are unsnappable in some browsers,
> while being snappable in others, leading to non interoperable behavior,
> and unreachable content in some browsers but not others, and authors
> not noticing when they use the "wrong" browser to test.
>
> In particular, at least the two following case aren't clear
> cut based on how I read the spec, but I think they should be:
>
> * Does it matter how far out an unreachable snap point is
> to determine if it "the most appropriate"? Can some unreachable
> snap points be so far out that they never are the most appropriate?

Up to the browser. For example, it's totally reasonable for a browser
to ignore a snap point if the element is *entirely outside* the
scrollable area, and therefore not visible at all.

> * 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?

~TJ

Reply | Threaded
Open this post in threaded view
|

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

Florian Rivoal-4

> On Jan 27, 2016, at 04:34, Tab Atkins Jr. <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

fantasai

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


Reply | Threaded
Open this post in threaded view
|

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

fantasai
On 04/06/2016 05:55 PM, fantasai wrote:
>
> 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.


[Sorry, this was randomly in my paste buffer. Please ignore.]

~fantasai

Reply | Threaded
Open this post in threaded view
|

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

Florian Rivoal-4
In reply to this post by fantasai

> On Apr 7, 2016, at 06:55, fantasai <[hidden email]> wrote:
>
>
> On 01/27/2016 11:36 AM, Florian Rivoal wrote:
>>
>> 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.
>
>
> 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.

Sorry for the belated answer. The prose in the spec has evolved a little since your mail, but the intent remains essentially the same as what you proposed. My comment takes these changes into account.

I believe that this phrasing mostly, but not entirely clarifies the situation. I guess I could live with it, but if possible, I would prefer a full clarification. What I believe is missing is a clarification in the "corridor" in section 6.2 (https://drafts.csswg.org/css-scroll-snap/#choosing), that would make it explicit that this discussion about excluding things that fall out of the corridor is not meant to exclude snap points that would be in the trajectory of the snapport but cannot be reached because we hit the end of the scroller first. The propose you mentioned above or the updated version of it says how to snap to an out of reach position when you want to, but it does not say whether you should, and the "corridor" discussion, although I believe it is only intended to exclude off-to-the-side elements, may also be understood to exclude too-far-ahead elements.

- Florian