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

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.

I have 2 questions about that apply to this type of scrolling:

1) Whether or not they trigger a scroll is out of scope, but when they do and that that scroll does not end on a snap point, should scroll-snap-padding still be taken into account? For instance, if you focus a button that was scrolled out of view, the scroll offset is changed to bring it into the visible area of the scroller. To the extend that it does not cause over-scrolling, should that instead be into the visible area of the scroller *reduced by the scroll-snap-padding* (aka snapport)? I think the answer should be yes.

The author is already telling us that this close to the edge isn't a good place to put things when you want them to be visible / usable, so I think we apply it not just to snappoints, but

Note: I don't think we should define where within the snappport, leaving that up to UAs is fine.

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

Note: I don't think the same concern applies to proximity snapping. Even if there is a proximity snap-point close to the place an indirect scroll would have taken you to, the UA is free to determine proximity as it wants, and can make a smart choice about snapping or not.

 - Florian

Received on Saturday, 30 January 2016 08:26:21 UTC