Position: sticky causes cursor to focus out of sight when using arrows keys to navigate textarea
Reported by
st...@timehero.com,
Apr 6 2018
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.108 Safari/537.36 Steps to reproduce the problem: 1. Create a position: sticky header and/or footer 2. Create a textarea that is scrolled out of view (ie. a form with multiple inputs) 3. Use the arrow keys to navigate the textarea rows What is the expected behavior? When the cursor goes outside of the visible area, the parent with the overflow should scroll so that the cursor is visible again. What went wrong? The height of the sticky header or footer are not considered when scrolling. The cursor ends up under the header or footer content. In the attached screenshot, the footer's background color has an opacity that allows you to see the cursor below. Did this work before? No Does this work in other browsers? No Same behaviour in Safari Firefox behaviour is worse cursor is never centred Chrome version: 63.0.3239.108 Channel: stable OS Version: OS X 10.13.2 Flash Version: We are trying to use sticky headers and footers on a form for our web app but this makes it a very bad user experience.
,
Apr 6 2018
vollick@, can you route this scrolling issue to the right person? Not clear to me if this is compositor or blink.
,
Apr 6 2018
,
Apr 9 2018
,
Apr 25 2018
Just wanted to bring up the scroll anchoring spec, specifically how 'scroll-padding' relates aside from *magically knowing sticky dimensions and state of stuck/unstuck. https://drafts.csswg.org/css-scroll-anchoring-1/#ref-for-propdef-scroll-padding
,
Apr 27 2018
Apologies for the delay in responding to this bug. I'm afraid that as far as I can tell, this is WAI according to the current sticky spec. We do not (and are not meant to) adjust the optimal scrolling region due to positioned elements (e.g. you can have a position:fixed header/footer as well and we will let you move the cursor out of sight underneath that). It is potentially a reasonable use-case (though I have some concerns about what happens if you have sticky boxes that are *not* naive headers/footers, as they can essentially be anywhere within their containing block), so if you would like to push for some sort of spec support (probably involving scroll-padding too), please open a spec issue at https://github.com/w3c/csswg-drafts/labels/css-position-3
,
Aug 3
As far as this issue filed to "wontfix" there has been some discussion in the wg relating to heuristics and 'scroll-padding' initially set to 'auto'. https://github.com/w3c/csswg-drafts/issues/2929 |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by dtapu...@chromium.org
, Apr 6 2018