Re: [css-snappoints][css-scroll-snap] Indirect scrolling

On Sat, Jan 30, 2016 at 12:25 AM, Florian Rivoal <florian@rivoal.net> wrote:
> The css-scroll-snap spec in section 7 talk esxplicitly about 3 kinds of scrolling, and implicitly about a fourth. The explicit 3 being:
> - explicit scrolling (e.g. grab the scrollbar thumb)
> - inertial scrolling
> - semantic scrolling (down arrow, page down, etc)
>
> The other type it is talking about in section 7.3 without naming it is the kind of scrolling that happens when a page is navigated to a fragment that defines a target element.
>
> I think there are more instances of this kind of scrolling, which I'm going to call indirect scrolling, where the user is doing an action that isn't itself a scroll, but triggers one. Here are the ones I can think of:
> - navigate to a fragment (as mentioned above)
> - Focusing an element (using js, or by pressing tab, or by using spatial navigation)
> - Moving the insertion caret in an editable element
> - inserting/deleting/replacing content in an editable element
>
> In all cases, which scroll offset you're supposed to end up at is not explicitly requested by the user, but there is a clear demand scrolling to somewhere that makes the relevant thing visible.

These "indirect" scrolling cases are all just "explicit" scrolls; the
scrolling element suddenly finds itself with a scroll position that
might not be a snap point, and no momentum/direction information.  So
yeah, snapping will happen as normal.

(This is why I need to rephrase the scroll categories to be about
having a position, or a direction/momentum, or both.  Much much
clearer that way.

> 2) What happens if we're under mandatory snapping, and the scroll they would trigger is in conflict with a
>
> For example:
> <div>
>   <img>
>   <button>press tab to focus me</button>
>   <img>
> </div>
>
> div { scroll-snap-type: mandatory; overflow: auto; height: 100vh; }
> div * { display: block; height: 100vh; }
> img { scroll-snap-type: center; }
>
> Scrolling to the button when it is focused seems bad, since if would violate the mandatory snapping, but not doing so seems bad as well, as it would make for a very confusing experience with active elements being off screen.
>
> I am not sure what the solution is, but here's a proposal: if scroll-snap-align is none on an element, but all of the following conditions are true, then scroll-snap-align computes to center (or some other value that's not none)
> - it is either focusable, or editable, or matches the :target pseudo class
> - it is a descendant of a scroller with mandatory snapping
> - all of its ancestors (up to the scroller with mandatory snapping) have scroll-snap-none
> (add some more careful working to deal with nested scrollers).

I don't think we need to do anything special about this.  mandatory
snapping is potentially hostile; we have some protections against
*accidental* hostility (via elements being larger than expected), but
this is *purposeful* hostility. The button isn't really reachable by
anyone, which is just bad page design.  This feels similar to a
negative margin pulling an element over top of a button; yes, the
button is tabbable, but it's invisible, and that's just the page's
fault.  We don't try and fix that.

~TJ

Received on Wednesday, 6 April 2016 20:39:42 UTC