Support input scroll-into-view #820
Labels
priority: p3/standard
Enhancement with nominal value or bug with nominal impact
size: md
type: enhancement
New feature or request
Describe your idea
If you focus on an input that is not visible (or would place your cursor in a location that is not visible) when that input is in a region which can be scrolled (eg, a ScrollContainer, like in the design browser when a field is partially outside of the visible region), it should be scrolled into view.
Motivation
This mirrors browser behavior and is in general an accessibility feature. This is important for a keyboard user who might tab to a field, and is just generally useful as if you write in a text input, you want to be able to see what you're writing
Proposed Solution
Initially this appears straightforward - in the case of ScrollContainer, set the html wrapper to
overflow: hidden
so that element is the one that gets scrolled, listen for the scroll event, then reset the scroll position and instead offset the scroll container by that amount (nb: would need to update everywhere we use scroll thumbs to be able to update themselves when the scroll container itself triggers a scroll). However this doesn't quite work since the wrapper covers the entire area of the canvas, not just the visible area - we rely on clip-path for that. But we can't just change the wrapper to use a position and width/height, because DOMObjects rely on being able to generate a transform matrix relative to the canvas, but this would cause the underlying html element to have a transform relative to the scroll container position instead. (Additionally, if we did something silly like rotating or skewing an input, this wouldn't account for that, though to be honest we probably want to actively avoid that).Other Information
See #819 for where this initially came up
The text was updated successfully, but these errors were encountered: