Intent to Ship: ScrollIntoView container option

[Chromestatus]

Contact emails

fla...@chromium.org

Explainer

None

Specification

https://drafts.csswg.org/cssom-view/#dom-scrollintoviewoptions-container

Summary

The ScrollIntoViewOptions container option allows developers to perform a scrollIntoView only scrolling the nearest ancestor scroll container. For example, the following snippet only scrolls the scroll container of target to bring target into view, but will not scroll all of the scroll containers to the viewport: target.scrollIntoView({container: 'nearest'});

Blink component

Blink>Scroll

TAG review

https://github.com/w3ctag/design-reviews/issues/1105

TAG review status

Pending

Risks

Interoperability and Compatibility

None

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1237)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/502)

Web developers: No signals

Other signals:

Ergonomics

None that I can think of.

Activation

It's possible to just use this feature as a progressive enhancement though I expect in practice most developers will want to polyfill falling back to scrollTo on non-supporting browsers. Detection of the feature can be done in Javascript by doing a test scrollIntoView, and if done in a position: fixed descendant should prevent highjacking the user's scroll.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/css/cssom-view/scrollIntoView-container.html?label=experimental&label=master&aligned

Flag name on about://flags

Experimental web platform features

Finch feature name

ScrollIntoViewNearest

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Measurement

Measured as web feature ScrollIntoViewContainerNearest

Sample links

https://output.jsbin.com/rihozik

Estimated milestones

Shipping on desktop	140
DevTrial on desktop	138
Shipping on Android	140
DevTrial on Android	138
Shipping on WebView	140

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

In https://github.com/w3c/csswg-drafts/issues/9452 there was consideration of passing an element to contain the scroll to. As discussed in https://github.com/w3c/csswg-drafts/issues/9452#issuecomment-2607879021 we think this is easily added in a backwards compatible way if there is a need for it.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5100036528275456?gate=5140738792488960

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67ab83a2.2b0a0220.2eae12.088a.GAE%40google.com

This intent message was generated by Chrome Platform Status.

[Alex Russell]

Is there an explainer or a motivating example anywhere?

Best,

Alex

[Robert Flack]

I've updated the chromestatus motivation to include a rough example of what developers do today compared to what this API enables. In particular, without this API developers building carousel components need to calculate the scroll offset to bring a particular slide into view and then call scrollTo or set scrollTop / scrollLeft on the scroll container directly in order to prevent highjacking the user's scroll (which can be observed in my demo link https://output.jsbin.com/rihozik in a browser which doesn't support the feature). e.g.

slideList.addEventListener('click', (evt) => {
  const target = evt.target.targetSlide;
  let scrollLeft = target.offsetLeft;
  const snapAlignInline = getComputedStyle(target).scrollSnapAlignInline;
  if (snapAlignInline != 'left') {
    // Adjust scrollLeft for element's snap alignment
  }
  // Also account for scroll padding, and scroll margin
  slideScroller.scrollTo({left: scrollLeft, behavior: 'smooth'});
});

With this API, developers can call scrollIntoView on the target of their buttons, e.g.

slideList.addEventListener('click', (evt) => {
  // scrollIntoView will automatically determine the position.
  evt.target.targetSlide.scrollIntoView({container: 'nearest', behavior: 'smooth'});
});

This has been highly upvoted on the github issue for exactly this reason - it enables developers to use scrollIntoView for these use cases without creating a disruptive experience.

[Yoav Weiss (@Shopify)]

LGTM1

[Alex Russell]

Per conversation at today's API OWNERS, LGTM1 contingent on there being a stand-alone explainer and example code. Bonus points for getting motivating example code into the spec too.

Best,

Alex

[Daniel Bratell]

LGTM3 (there are two LGTM1 so next is 3). Note Alex' request.

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7d48c206-9e1c-4b68-9ff9-1369c0f08ae8n%40chromium.org.

[Robert Flack]

Thanks, I added an example to the spec with rationale of why you might use this: https://github.com/w3c/csswg-drafts/pull/12450.

[Jeffrey Yasskin]

Thanks!

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TPqsUhQhCYUECX7g7ier6WONXb0Gyadud%2BE4kHn89Xt4Q%40mail.gmail.com.