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

> On Jan 26, 2016, at 04:29, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> On Sun, Jan 24, 2016 at 4:07 AM, Florian Rivoal <florian@rivoal.net> 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

Received on Tuesday, 26 January 2016 03:10:21 UTC