Define steps for scrolling element into view

[LJWatson]

Migrated from Bugzilla #27913.

Ping @rodneyrehm

[rodneyrehm]

This issue is discussed in whatwg/html#94 - I'm not sure who's got the lead here, WHATWG or W3C…

[travisleithead]

I'm flexible. From the other issue, it looks like the scrollIntoView hook in CSSOM View has been added (w3c/csswg-drafts#81), so we just need to link into it at the appropriate place. I'd prefer a PR here, of course, but can integrate a change from WHATWG easily enough :)

[jihyerish]

I noticed that scrolling triggered by focusing input elements behaves differently in browsers.

If there is a value for each input element, in Firefox(53), the scrolling stops when the value of the input element comes into view even if the input element is partially visible.
However, other browsers(Chrome, Safari, Opera) always show the focused input element entirely within the scroll view area.
See the usecase: https://jsfiddle.net/JihyeHong/7bgfvycy/

Is this just a bug of Firefox?
Or Is this usecase considered for defining steps for scrolling element into view?

I bring this up because the discussion in Bugzilla ( https://www.w3.org/Bugs/Public/show_bug.cgi?id=27913) was moved to here. : )

[chaals]

@jihyerish:

If there is a value for each input element, in Firefox(53), the scrolling stops when the value of the input element comes into view even if the input element is partially visible.
However, other browsers(Chrome, Safari, Opera) always show the focused input element entirely within the scroll view area.

I think it's "sub-optimal" implementation in Firefox, which is a kind of bug.
There is a problem with the idea of "being in view" which is that you can never be entirely sure how much is viewed - as well as the browser window and zoom, you get people working with system-level magnification.

So as @rodneyrehm said elsewhere I think we should keep some leeway in where exactly scrolling puts things, which would allow current behaviours.

Finally it doesn't look like anyone has made much progress on this. @travisleithead do you think you're going to get this covered with the current milestone? Does anyone want to pick it up and deal with it?

[fenduru]

I'm working on a virtualized rendering component that manually controls the positioning of elements using translate. Rather than using typical scrolling, I set overflow: hidden. When an element gets focus, even though it is visible, the browser thinks it is in a different position and will scroll to an incorrect location. I have to manually set the scrollTop/scrollLeft back to zero after this happens, which can cause some jank.

It would be great if this was spec'd such that I could prevent this container from ever scrolling.

[scottaohara]

for review: Fix 'scroll an element into view' invocations

[siusin]

We're closing this issue on the W3C HTML specification because the W3C and WHATWG are now working together on HTML, and all issues are being discussed on the WHATWG repository.