- From: Majid Valipour <majidvp@chromium.org>
- Date: Mon, 16 Jul 2018 12:17:33 -0400
- To: Hazel Seanor <hazel.seanor@gmail.com>
- Cc: www-style@w3.org
- Message-ID: <CAB8RdXu_LyZC_qgfz77cw-ED3m54XpUoF-q2OsgkFc95Kcw8oA@mail.gmail.com>
On Mon, Jul 16, 2018 at 11:12 AM Hazel Seanor <hazel.seanor@gmail.com> wrote: > Hello, > > When scrolling on web pages using the space or page down keys, the browser > takes the viewport height and scrolls down by that amount. This is normally > fine (and expected behaviour) except when fixed headers are used. Because > the entire page size is used and not just that which is visible to the > user, the page scrolls down too far and a few lines of text end up > positioned behind the header. > > The issue is further described in this Bugzilla thread from 6 years ago: > https://bugzilla.mozilla.org/show_bug.cgi?id=780345 > > Firefox's solution was to detect when a fixed header was being used and > adjust for it, but this doesn't detect all fixed headers (possibly because > there are multiple ways to implement fixed headers) and while other > browsers may have implemented this or something similar, Chrome has not. > > It is also possible to account for this with JavaScript, but this is far > from an ideal solution. It seems to me like something that should be able > to be manipulated with CSS. As well, as an accessibility concern, it should > be something that can be fixed across all browsers. > > My proposed solution would be to add a new property, scroll-amount, which > would be set to a size in units. > > I believe this is already addressed by `scroll-padding` [1]. The property adjusts the optimal viewing region for a scroll container. While the usage was initially limited to css-scroll-snap but it has since been generalized to apply to all scrolling operations that need to now the scroll port size (e.g., page up/down, Element.scrollIntoView etc.). Authors can use this to exclude parts of the scroll container that are obscured by fixed position elements. The specification explicitly calls this out as an intended usage. [1] https://drafts.csswg.org/css-scroll-snap/#scroll-padding > This addresses a separate concern from CSS Scroll Snap because when > scrolling with CSS Scroll Snap, you are brought to a predefined point on > the page. The point of this change would be to allow a developer to define > how far each button-press would scroll down the page, from any point to any > point. > The revised spec no longer allows pre-defined points but rather pre-defined target elements. Specifically PageDown, PageUp are considered scroll operations with intended end and direction. So their selected snap area depends on the operation intended end which hould already be adjusted to take `scroll-padding` into account. So I am not sure if this is still a problem. > I haven't made a github issue because I'm not sure what to tag it as. > If `scroll-padding` does not address this problem then I suggest creating a github issue and tagging it with css-scroll-snap. Majid
Received on Monday, 16 July 2018 16:18:10 UTC