Small ping, it's been some time (maybe my response went into the spam
folder or something). I still wonder how to best feature detect it?
Jacob G schrieb am Montag, 28. Juli 2025 um 13:47:21 UTC+2:
> I'm not sure if I'm 'allowed' to ask in this mailing list (I'm not an API
> owner or anything - just a curious web dev), but:
>
> I really love this new option, as scrollIntoView's scroll hijacking
> behavior has bitten me in the past too (so I also think this solves a real
> big problem of the web platform). I have one request though:
>
>
> > 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.
>
> Could you please add an example for that? I assume you're thinking
> something like `<div style="position:fixed;top:1px"><div
> id="scrollToThis">`, then calling `window.scrollToThis.scrollIntoView({
> container: 'nearest' })` on page load. If `window.scrollY === 0` it is
> supported, otherwise it isn't?
> Asking, because having a copy & paste-able example would make it easier
> for both humans and AI agents to adopt this :)
> jyas...@chromium.org schrieb am Freitag, 4. Juli 2025 um 16:53:27 UTC+2:
>
>> Thanks!
>>
>> On Fri, Jul 4, 2025, 7:49 AM Robert Flack <fla...@chromium.org> wrote:
>>
>>> Thanks, I added an example to the spec with rationale of why you might
>>> use this: https://github.com/w3c/csswg-drafts/pull/12450.
>>>
>>> On Wed, Jul 2, 2025 at 11:27 AM Daniel Bratell <brat...@gmail.com>
>>> wrote:
>>>
>>>> LGTM3 (there are two LGTM1 so next is 3). Note Alex' request.
>>>>
>>>> /Daniel
>>>> On 2025-07-02 17:26, Alex Russell wrote:
>>>>
>>>> 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
>>>>
>>>> On Wednesday, June 25, 2025 at 1:20:00 PM UTC-7 Robert Flack wrote:
>>>>
>>>>> 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 <sligh...@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+...@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
>>>>
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7d48c206-9e1c-4b68-9ff9-1369c0f08ae8n%40chromium.org?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>> --
>>> 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/CAJh39TPqsUhQhCYUECX7g7ier6WONXb0Gyadud%2BE4kHn89Xt4Q%40mail.gmail.com
>>>
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TPqsUhQhCYUECX7g7ier6WONXb0Gyadud%2BE4kHn89Xt4Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
--
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/9f73a19c-56dc-460d-98bc-a8e41744e40an%40chromium.org.
