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

On Mon, Jan 25, 2016 at 7:09 PM, Florian Rivoal <florian@rivoal.net> wrote:
>> 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.

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

Received on Tuesday, 26 January 2016 19:35:16 UTC