W3C home > Mailing lists > Public > public-css-archive@w3.org > December 2018

Re: [csswg-drafts] [css-scrollbars][proposal] Define the scrollable area of an element (#3428)

From: jonjohnjohnson via GitHub <sysbot+gh@w3.org>
Date: Wed, 12 Dec 2018 13:19:08 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-446585141-1544620747-sysbot+gh@w3.org>
@upsuper I think the key distinction is wanting scrollbars to match the "visually" scrollable part of a scroll container, when parts of the container could be covered by fixed or sticky elements from its flow,  or even an element outside that partially covers the scroll container, like "[hidey bars](https://github.com/w3c/css-houdini-drafts/blob/master/scroll-customization-api/UseCases.md)" that many native mobile apps have, think the twitter or reddit apps.

So put simply, a vertical scrollbar always runs the full height of a scroll container. What if we had a property that could set the the scrollbar/track in from that top and bottom edge? Say the height of a translucent fixed header that is 50px tall? Something like `scrollbar-inset: 50px 0`?

I know some browsers even have a few heuristics in place to analyze what "page down/up" means when fixed elements cover some of the scrollport, and an initial value of `auto` could possibly lend property to be used alongside those heuristics?

A simple as "I'd like this scrollbar to not run whole length of my scroll container, and instead leave space for a sometimes animated fixed header and footer so the scrollbar starts and ends alongside those elements and doesn't cover them.

Of course this is all in relation to "overlay" scrollbars, not scrollbars that take up place in the box tree.

PS Did my talk of `transform`/`perspective`/`sticky` not make any sense when reasoning about how they interact with scroll containers and desiring to place a scrollbar in ways it's currently limited? The linked test case showing the scrollbar way off screen?

Also, back around chrome 42 there was a bug from non-zero border radius on scroll containers that made scrolling overflow still visible. This bug afforded something similar to this feature. Here's a gif of it...
It's just asking for a scrollbar that wouldn't run the full length/edge of the scroll container.

GitHub Notification of comment by jonjohnjohnson
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3428#issuecomment-446585141 using your GitHub account
Received on Wednesday, 12 December 2018 13:19:20 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:41 UTC