[css-scroll-snap] Snap point selection when scrolling into view should try to make targeted element visible

[flackr]

The css-scroll-snap-1 6.2 Choosing Snap Positions specification does not require scrolling the target into view unless the target itself establishes a snap position. As a result, scroll snap can result in a scrollIntoView or anchor navigation not actually scrolling to the correct snap position to show the target element.

For example, consider a scroller which has pages that snap into view and each page contains items which are sometimes scroll targets. Calling scrollIntoView on a target can result in scroll snap selecting the next or previous position. See a live demo

<style>
.scroller {
  overflow: x mandatory;
  scroll-snap-type: x mandatory;
  width: 300px;
}
.page {
  scroll-snap-align: center;
  display: inline-block;
}
.target {
  width: 100px;
  display: inline-block;
}
</style>
<div class="scroller smooth">
  <div class="page">
    <div class="target" id="t1">1</div>
    <div class="target" id="t2">2</div>
    <div class="target" id="t3">3</div>
  </div>
  <div class="page">
    <div class="target" id="t4">4</div>
    <div class="target" id="t5">5</div>
    <div class="target" id="t6">6</div>
  </div>
  <div class="page">
    <div class="target" id="t7">7</div>
    <div class="target" id="t8">8</div>
    <div class="target" id="t9">9</div>
  </div>
</div>

On this example (try it in the live demo), the following issues occur:
Starting from page 1,

• clicking on item 4 does not scroll,
• clicking on item 7 scrolls to page 2, but should scroll to page 3.

Starting from page 2,

• clicking on item 3 or 7 does not scroll.

Starting from page 3,

• clicking on item 6 does not scroll
• clicking on item 3 scrolls to page 2, but should scroll to page 1.

I believe this affects all operations attempting to scroll elements into view.

TLDR; I think the snap point selection algorithm should require that we select the snap area which results in the target element being visible. There may be situations where there is no such snap area, in which case I think it's okay that we scroll as close as we can to the target, but this case has a clear expectation.

[css-meeting-bot]

The CSS Working Group just discussed [css-scroll-snap] Snap point selection when scrolling into view should try to make targeted element visible, and agreed to the following:

• RESOLVED: We'll fix the problems in this issue, details TBD

The full IRC log of that discussion

<TabAtkins> flackr: in scroll snap, we have logic for if you try to scroll an element that defines a snap area. since we know it has a desired span alignment, we will respect that rather than putting it into the top-left
<TabAtkins> flackr: but if you ahve an ancestor with a preferred snap, we dont'. that can be degenerate - if you scroll the element into view, the ancestor's snap can scroll the element out of view.
<TabAtkins> flackr: so my proposal is we change the spec to consider ancestors of the targeted scrolled-to element; if they have a snap area defined, we snap to that and then try to scroll the targeted element into view
<TabAtkins> flackr: there's some details tbd, but we shouldn't change the snap after the scroll
<astearns> ack fantasai
<TabAtkins> fantasai: fixing this makes sense. if the element has a snap area, snapping to that is ideal, walking the ancestor chain is only needed insofar as it brings the elment into view
<TabAtkins> fantasai: the behavior we want might be different on mandatory vs proximity snapping
<TabAtkins> fantasai: so agree to fix this, but i think it's more ocmplicated than just choose closest ancestor
<TabAtkins> flackr: agree, it's choose closest ancestor *while* scrolling lement into view, some combo of that
<TabAtkins> fantasai: we could resolve that, to the extent that other snap areas *interfere* with bringing the element into view, we might not honor the element's own snap
<TabAtkins> flackr: the element also might not have snap, tho
<TabAtkins> flackr: we should resolve that a scrollTo *should* put the element into view, and we need to figure out precisely what that means wrt ancestors with snap positions
<TabAtkins> astearns: So proposed is "fix the issue, Rob figures out the details"
<TabAtkins> fantasai: [missed, but in agreement]
<TabAtkins> astearns: proposed is we will address the problems enuemrated in this issue
<TabAtkins> RESOLVED: We'll fix the problems in this issue, details TBD