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.
On Wed, Jun 25, 2025 at 11:25 AM Alex Russell <slightly...@chromium.org>
wrote:
> Is there an explainer or a motivating example anywhere?
>
> Best,
>
> Alex
>
> On Thursday, June 19, 2025 at 9:24:22 AM UTC-7 Chromestatus wrote:
>
>> 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
>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EScroll%22>
>>
>> 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
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ? 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
>> <https://chromestatus.com>.
>>
>
--
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+unsubscr...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TM0gfDLYM%2Bw6Fen%3DNYqQMX9NGHfeaht-apqqvnTNLoBnQ%40mail.gmail.com.
