W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2016

Re: [csswg-drafts] [css-overflow] overflow: Consider support for overlay scrollbars

From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
Date: Wed, 10 Aug 2016 17:28:16 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-238940665-1470850095-sysbot+gh@w3.org>
Results of the telcon, in my words:

* The WG is in agreement that the problem to solve is eliminating the 
"jiggle"/relayout that occurs due to "overflow:auto" adding a 
scrollbar (and thus reducing the space available for content) only 
when the content overflows.
* Forcing overlay scrollbars is one way to accomplish this, but Apple 
is opposed to that (as they consider overlay-or-not to be a choice 
firmly in the user's hands), and Chrome would likely have issues 
pushing that scenario on Windows UI, too.
* Boiled down, then, what we absolutely need is a value that reserves 
the same amount of space whether the scrollbar is shown or not.
* There's a subissue regarding overlay scrollbars: if the system uses 
overlays, should it still reserve the space that intrusive scrollbars 
would require? Both sides have useful arguments: "no" gives minimal 
disruption, making this value identical to the other scrolling values 
when the user wants overlays; "yes" is a common request of authors, 
who want to ensure that no content sits under the scrollbar even 
during transient scrolling.

Thus, I propose two values (names pending):

**value1**: Acts like "auto" (doesn't show a scrollbar when the 
content doesn't overflow), but when using intrusive scrollbars, 
reserves the space the scrollbar would take up if it was there. 
(Overlay scrollbars continue to take up zero space regardless of 
content size.)

**value2**: Acts like value1, but reserves the intrusive-scrollbar 
size at all times, even when scrollbars are overlay.

We should then permanently shelve the idea of standardizing the 
"overlay" value, and commit to "overlay vs intrusive" being a 
user/platform choice uncontrollable by CSS.

Parallel to this, we should restart the discussion of a "scrollbar 
width" unit or keyword, so people can reserve space on both sides of 
an element.

Parallel to this, we should discuss if Houdini Layout'd elements 
always require a "stable" overflow value, such that "overflow: auto" 
is treated as one of the above two values (probably value1) on 
Houdini'd elements. That would let us chop out a big chunk of 
complexity from the layout API that authors will probably usually get 
wrong anyway.

(I'll internally start a discussion about whether Chrome might want to
 switch `auto`'s behavior in general to match one of these values, 
again probably value1, so that we *never* have unstable scrollbars.)

GitHub Notification of comment by tabatkins
Please view or discuss this issue at 
using your GitHub account
Received on Wednesday, 10 August 2016 17:28:24 UTC

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