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 <bratel...@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 <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/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+unsubscr...@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/CANh-dX%3DhKn0DeddnisMNsHi7-jxjpSUAHNM_SGMWjDiFT7torA%40mail.gmail.com.
