Add an HTMLElement.focus smooth scroll option

[LifeIsStrange]

When we focus an element in the DOM, the default behaviour is to autoscroll to the element. The scrolling can be disabled with the option preventScroll: true;

The manual way to scroll would be to call https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView ScrollIntoView has a behaviour option which allow to define smooth scrolling instead of the default (instant teleport "scrolling").

Since smooth scrolling is often the desired behaviour and since we very often want scrolling on focus, it would be nice to provide a smooth scrolling behaviour option for focus directly instead of having to workaround the issue (and I suspect the easiests workaround hinder scrolling performance/framerate).

[yoavweiss]

/cc @flackr - thoughts on the above?

[flackr]

This seems reasonable, though for future proofing I wonder if we should provide a scrollIntoViewOptions rather than duplicating those options here. If we didn't already have preventScroll: true I would have proposed something like using a single parameter scroll or scrollOptions to both determine whether we scroll and set the options for that scroll, but we could just add scrollOptions or scrollBehavior.

[flackr]

As an example, we would like to add a way for the scrolling APIs to be contained to some scroller rather than scrolling all scrollers to the root: https://github.com/w3c/csswg-drafts/issues/10451 . It makes sense you'd want to support that here too.

[e-oz]

@flackr focus() and scrollIntoView() might be quite different. Here you can see how Safari iOS (in the emulator) scrolls an input on focus, and the difference with scrollIntoView():

Focus:

https://github.com/user-attachments/assets/351ccaf1-323f-41e3-9dca-67cfe6ecbe5c

scrollIntoView():

https://github.com/user-attachments/assets/120f395a-9206-4452-83aa-e0760bc659c4

[flackr]

@flackr focus() and scrollIntoView() might be quite different.

To align with focus behavior, the default scrollIntoViewOptions would need to be {block: 'nearest', inline: 'nearest'} which minimizes the scrolling to bring the target into view.

[e-oz]

@flackr almost ;) If we tap the input after scrollIntoView({block: 'nearest'}), it still scrolls a bit:

https://github.com/user-attachments/assets/1d2c7bb6-cbd4-489b-9728-5476cabf7678

focus(), for comparison:

https://github.com/user-attachments/assets/cd4a4375-3a77-4419-bd6a-16ecb80160a1

But perhaps it’s just peculiarities of Safari’s implementation.

[flackr]

Can you explain the difference in your video? I see scrolling when the input is focused in both?

I believe that the target region for Element.scrollIntoView is the border box, where for focus I think it is actually the current editing caret in the textbox. This may explain why you wouldn't be able to perfectly replicate focus scrolling with Element.scrollIntoView.

[e-oz]

@flackr in the first video (from my previous comment), when I click “Add” and the form is displayed, I call scrollIntoView({block: 'nearest'}) for the first input field (sorry that the pointer clicks aren’t marked in the video). It scrolls almost perfectly, but when I tap the input field, Safari still scrolls the page a bit. When I use focus(), it just focuses, and the user can start typing without any extra page movements.