W3C home > Mailing lists > Public > www-style@w3.org > July 2018

Re: Proposal: define scroll amount via CSS

From: Majid Valipour <majidvp@chromium.org>
Date: Mon, 16 Jul 2018 12:17:33 -0400
Message-ID: <CAB8RdXu_LyZC_qgfz77cw-ED3m54XpUoF-q2OsgkFc95Kcw8oA@mail.gmail.com>
To: Hazel Seanor <hazel.seanor@gmail.com>
Cc: www-style@w3.org
On Mon, Jul 16, 2018 at 11:12 AM Hazel Seanor <hazel.seanor@gmail.com>

> 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

>  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.

Received on Monday, 16 July 2018 16:18:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:11 UTC