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

[csswg-drafts] [css-overflow] Add mechanism for disabling scrollbars

From: Rick Byers via GitHub <sysbot+gh@w3.org>
Date: Mon, 22 Aug 2016 21:42:58 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-172562366-1471902176-sysbot+gh@w3.org>
RByers has just created a new issue for 

== [css-overflow] Add mechanism for disabling scrollbars ==
Split from [the discussion of overflay 
 Key bits of the argument:

I said:

> A related argument for overflow-style: I think there are legitimate 
use cases for disabling scrollbars entirely. Eg. a horizontally 
scrollable tab strip - @esprehn tells me polymer and facebook 
apparently rely on a hack for this where they place the strip inside a
 overflow:hidden container that is 20px shorter in order to clip the 
scrollbar. Some sites also rely on -webkit scrollbar theming for this.
 Edge has -ms-overflow-style: none for this, we should standardize 
that too.

@tabatkins said:

> If you're wanting it to be pannable but not scrollable, that's a bit
 user-hostile - it'll only be scrollable on touch devices. Having 
something that turns off scrollbars when the user is capable of 
panning sounds okay, tho.

I said:

> Good point, though it's not just "touch" devices - you can still 
scroll with a mousewheel etc. Perhaps we need more concrete use cases 
here - presumably people are either breaking scenarios where 
scrollbars are the only way to scroll, or using this only as a 
convenience UI when there is some other navigation mechanism. eg. for 
a tab strip, you can click on the left or rightmost tab and it'll 
recenter to show more further left/right. The Android homescreen is an
 interesting use-case too - it doesn't have a scrollbar, but a custom 
"dot" indicator showing the active screen (and in mouse cases you 
could presumably click on the dot you want). Scenarios like this will 
probably be more common when developers switch to using css snap 
points (instead of custom JS scrolling) - those often have alternate 
navigation UI (at least next / previous buttons). Of all the image 
carousels I've seen on the web, I don't think I've ever seen one with 
a scrollbar. We want to support those scenarios as native scrollers 

@tabatkins  said:

> Definitely. The hard part is designing things that degrade well, and
 making the badly-behaved things possible but not the easiest thing to
 reach for. ^_^

> For example, a "panning" overflow-style could hide the scrollbars 
when the device is capable of panning, and default to showing 
scrollbars otherwise. We could then have a property controlling that 
default, and allow people to say they'll handle those cases manually, 
with a property/value name that makes it less attractive, defaulting 
to the safe scrollbar-showing behavior.

 @alexelias added:

> This is useful for image carousels, chat boxes, and for replacement 
by JS bespoke scrollbars for contact lists and photo albums. Without 
vendor prefixes, it can only be achieved with [complex, bug-prone box 
 or touch-handler fake scrollers.

> @tabatkins's objection was that we don't want to make it too easy to
 make sites unusable for users who prefer to click on the scrollbar, 
and he suggested:

>> For example, a "panning" overflow-style could hide the scrollbars 
when the device is capable of panning, and default to showing 
scrollbars otherwise.
I think tying this to input capabilities is too weird. Some somewhat 
saner variants would be to tie it to overlay-or-not, or possibly 

> But, personally my preference would be to just have a value3 that 
hides any scrollbar entirely and reserves no space, as I think having 
a rational platform is most important here. I've yet to run into a 
site abusing the existing vendor-prefixed properties to accidentally 
hide a useful desktop scrollbar, so I doubt standardizing the 
capability would lead to a problem either.

I'd add that the concerns about misuse apply to all the extensible-web
 things we're doing (Houdini etc.).  If we're every going to have a 
rational layered platform (eg. where scrollbars can be explained as a 
feature built on top of lower-level primitives), then we need to have 
knobs that let developers disable built-in behavior if favor of their 
own custom behavior.  To minimize the risk we should just do our 
absolute best to ensure that all the common use cases are best solved 
by the built-in behavior. 

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/419 using your GitHub 
Received on Monday, 22 August 2016 21:43:05 UTC

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