[css-overflow][cssom-view] Set the option for scrolling behavior triggered by focus

[jihyerish]

Element.focus() is used the UA may scroll the element into view. The result is reasonable when focusing based on onkeydown. But when focusing by mouseover the element, focus event also triggers the scroll behavior.

The input device of the smart TV is the remote controller. Focusing an element with the remote controller is based on pointing(mouseover) and pressing buttons(onkeydown).
Focusing by mouseover may bring too much scrolling. This behavior doesn't meet with the requirement of TV app developers and users and it isn't good UX for the smart TV.

Demo shows no scrolling behavior when focusing by mouseover. If the option isn't checked, it also shows the result of the default scroll behavior triggered by Element.focus().

It could be nice if we can disable the scrolling behavior when the focus is triggered by mouseover or for other use cases.
Customizing the scrolling behavior of Element.focus already been discussed in whatwg/html#834.

I think there could be some approaches for this:

1. New Property - focus-scroll
   could customize the scrolling behavior when it's applied to the scrollable area.

Value: auto | none | smooth

• auto: Element.focus() makes the element scroll into view
• none: Element.focus() doesn't make the scrolling behavior
• smooth: Element.focus() makes the element come into view with smooth scrolling

or

2. Add scrollOptions as a parameter for Element.focus()
   could customize the scrolling behavior triggered by focus.

Element.focus(scrollOptions);

scrollOptions
{
  behavior: "auto" | "none" | "smooth",
  block: "start" | "end"
 }

• auto: Element.focus() makes the element scroll into view
• none: Element.focus() doesn't make the scrolling behavior
• smooth: Element.focus() makes the element come into view with smooth scrolling

scrollOptions refers to the scrollIntoViewOptions of Element.scrollIntoView().

The naming of focus-scroll may not proper, and the second approach; adding scrollOptions would be more reasonable.
I'm think many developers need this feature.

[jihyerish]

/cc @RByers @zcorpan @frivoal could you give me thoughts on this issue?

[frivoal]

When the UA is doing the focusing itself, based on the tab key or actual mouse focusing, I believe this is probably OK to leave as a quality of implementation.

But when you are doing the focusing via javascript, I can see how the UA, lacking some information about the context and about why something is being focused, could do it wrong (and scroll too much, or in ways unexpected to the user). So having some way to control that seems useful.

Since you want different scrolling behaviors depending on how the script triggers the focus, I think that the parameter to Element.focus() makes more sense than the css property.

I think maybe the values should be different though, as I am not sure "none" is a desirable value. Having a focused element be entirely off screen doesn't sound good. Maybe the choice is more between:

1. when focusing an element, if it is not already entirely within the optimal viewing region, scroll to put it there.
2. when focusing an element, if it is already partly within the optimal viewing region, don't scroll. If it is entirely outside, do scroll.

That said, option 2 still has issues: if only 1px is in the optimal viewing region, you probably want to scroll anyway. But where is the threshold?

[jihyerish]

why something is being focused, could do it wrong (and scroll too much, or in ways unexpected to the user).

Yes, this is what I intend to solve.

Maybe the choice is more between:

Are both options for the behavior of "none" value?
If so,
if the focus() could have the value "none", the scroll behavior would be defined under two cases:

• when the focused element is partly within the optimal viewing region
• when the focused element is entirely outside the optimal viewing region

For case 1, the element don't scroll.
And for case 2, the result would be scrolling element entirely into the optimal viewing region.
The behavior in case 2 makes the naming of the value "none" not suitable because the meaning of the term doesn't match with its behavior. I guess you also thought that "none" is a desirable value because of this.

if only 1px is in the optimal viewing region, you probably want to scroll anyway. But where is the threshold?

When having the "none" value, the element don't scroll even if the 1px of it is in the optimal viewing region. What would be the use case when the threshold is needed?

[frivoal]

Are both options for the behavior of "none" value?

No, I mean my first option to be similar to "auto", and my second to be instead of "none".

When having the "none" value, the element don't scroll even if the 1px of it is in the optimal viewing region. What would be the use case when the threshold is needed?

I don't know if a threshold is the right way to go about this, but it seems to me that from a user point of view, an element being completely outside the optimal viewing region and and element only having 1px inside it are pretty much the same.

[jihyerish]

I don't know if a threshold is the right way to go about this, but it seems to me that from a user point of view, an element being completely outside the optimal viewing region and and element only having 1px inside it are pretty much the same.

I considered to use "none" value when the scrolling behavior triggered via focusing by mouseover.

So if we could use "none" value for focus(), when we consider an element only having 1px inside the optimal viewing region behave to scroll inside it, the mouseover would trigger scroll too much.
I'd like to solve this problem by no scrolling behavior on that condition.
Also the threshold wouldn't be needed because we can mouseover the 1px of the element which is inside the optimal viewing region.

I think the same scroll behavior by focus for both an element being completely outside the optimal viewing region and an element only having 1px inside it could be implemented by "auto" value.

[frivoal]

Right. If you're using it with mouseover, then a threshold of 1px is probably fine.