You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to see a more finely tuned scrollIntoView API. If this is not the right place for spec issues, please direct me to the correct place.
The spec as it stands does not handle well elements which are larger than the scrolling viewport. All options for block and inline assume the whole element size in that dimension is required to be in view.
Consider for example the requirement to scroll an event bar into view in a Gantt chart. The event may be part of a very long running project.
When using inline : 'nearest', the application may not want the behaviour which attempts to scroll the entire element width into view.
Clicking the "Bring event bar into view" button uses the DOM standard API, and the browser scrolls as much of the element as possible into view.
Of course this can be worked round. I have my own API for this which does all the acrobatics. But this is what the scrollIntoView API is for!
Also, there needs to be scrollMargins which work if the target element is smaller than the viewport. inline : 'nearest' sometimes wants the target to be brought a little further into the view than exactly nearest. Just to show some space around the target to indicate that it is all in view.
Also(!) the API should return a Promise which completes after behavior : 'smooth' has completed the scroll. Awaiting for things is sometimes needed.
What is needed is below. It animate-scrolls the inline fully into view, and the block, just the nearest 100 pixels. And it resolves a Promise when done so that that popup can align to it when it is in its final place (Though as you see, it realigns on scroll). Basically I have had to re-implement this API in a manner which is actually useful to developers! I cannot use the standard DOM API at all in this suite of products. (This is a common problem in all the recent committee-designed HTML enhancements. <input type="somethingExotic"> is almost never usable in real world apps)
Regarding https://drafts.csswg.org/cssom-view/#scroll-a-target-into-view
I would like to see a more finely tuned
scrollIntoViewAPI. If this is not the right place for spec issues, please direct me to the correct place.The spec as it stands does not handle well elements which are larger than the scrolling viewport. All options for
blockandinlineassume the whole element size in that dimension is required to be in view.Consider for example the requirement to scroll an event bar into view in a Gantt chart. The event may be part of a very long running project.
When using
inline : 'nearest', the application may not want the behaviour which attempts to scroll the entire element width into view.I propose further options which change the size of the "target bounding border box" after it has been determined at step 2 of https://drafts.csswg.org/cssom-view/#element-scrolling-members.
In this hypothetical Gantt chart, the application may only require that at least 100 pixels of the bar's width be in view to operate on it.
Run this Codepen: https://codepen.io/Animal-Nige/pen/LYajyBQ
Clicking the "Bring event bar into view" button uses the DOM standard API, and the browser scrolls as much of the element as possible into view.
Of course this can be worked round. I have my own API for this which does all the acrobatics. But this is what the
scrollIntoViewAPI is for!Also, there needs to be
scrollMarginswhich work if the target element is smaller than the viewport.inline : 'nearest'sometimes wants the target to be brought a little further into the view than exactly nearest. Just to show some space around the target to indicate that it is all in view.Also(!) the API should return a Promise which completes after
behavior : 'smooth'has completed the scroll. Awaiting for things is sometimes needed.What is needed is below. It animate-scrolls the
inlinefully into view, and theblock, just the nearest 100 pixels. And it resolves a Promise when done so that that popup can align to it when it is in its final place (Though as you see, it realigns on scroll). Basically I have had to re-implement this API in a manner which is actually useful to developers! I cannot use the standard DOM API at all in this suite of products. (This is a common problem in all the recent committee-designed HTML enhancements.<input type="somethingExotic">is almost never usable in real world apps)scrollEvent.mov