[css-scrollbars] Add mechanism for disabling scrollbars

[RByers]

Split from the discussion of overflay scrollbars. 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 right?

@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 tricks 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 scrollbar-absorbs-clicks-or-not.

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.

[frivoal]

Split from the discussion of overfay scrollbars.

Note that the two discussions may still need to influence eachother, as if we end up wanting both, they may (or not) end up in the same property, and influence its name and the name of its values.

[tabatkins]

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

Note that we have that value; it's called hidden. It's not pannable, but you can scroll via script. So we're not trying to explain anything fundamental here, we're trying to give a more convenient shorthand for some case that might be common enough to be worth simplifying - making something scrollable but not showing scrollbars (at least, on devices that make it easy to scroll via some direct gesture).

[alexelias]

I don't agree this proposal amounts to a "convenient shorthand". We need this property to have a rational layered platform.

There are two completely distinct underlying primitives, hiding the scrollbar UI and disabling user panning. "overflow: hidden" opinionatedly conflates them. As I said, the only two ways to change the look/functionality of the scrolling UI otherwise are A) small-clip-box-containing-larger-scroll-viewport madness, or B) reinvent touch gesture handlers in JS. That's a sign this is not simply a "convenience".

[tabatkins]

When you get down to primitives, plenty of things aren't convenient anymore; you often have to reinvent bits that you've lost along the way. The reason I'm arguing that this isn't a "primitive" is because it gets rid of some of the methods for users to scroll the box, but not all of them. It's halfway down the stack.

But arguing over which is more primitive isn't a fruitful exercise; if we can agree, great, but if we can't, belaboring the point doesn't get us anywhere (we're just slicing things differently). I'm still stuck on the fundamental usability issue I raised earlier - when you remove scrollbars, how are people supposed to scroll on devices without panning functionality? This is why I've been pushing back against this - it looks very easy for this to be very user-hostile when naively used on "mobile-first" designs without being usability-tested on desktops (particularly ones without a mousewheel, which at least allows vertical "panning").

hidden at least has the benefit that no one can scroll it without scripting or navigation, so it's more obviously necessary to provide user affordances, and those manually-added affordances are more likely to be tested, leading to people being more likely to remember how desktops work.

Thus my earlier suggestion of having the value only hide scrollbars on devices where the UA knows that panning is a primary scrolling mechanism - phones and tablets, maybe some touch-focused laptops. Then maybe we can also have a less-conveniently-named value that actually turns off scrollbars all the time, which makes it clearer what the author's responsibilities are.

[alexelias]

(particularly ones without a mousewheel, which at least allows vertical "panning").

The problem is OSes in general do not necessarily provide a hook to tell us whether a touchscreen, mousewheel or touchpad is present. We can confirm one exists once we get an input event, but prior to that we have no real idea (and we can never prove the negative). We'd be forced to rely on crude heuristics.

it's more obviously necessary to provide user affordances, and those manually-added affordances are more likely to be tested

The main use I have in mind is precisely developers who want to manually provide an alternate scrollbar affordance (e.g. contact list big-letter scrollbar). Your proposal raises the risk of double-scrollbar glitches, then. You'd be forcing webdevs to detect whether the UA scrollbar is present or not in order to disable their superior bespoke scrollbar...

Then maybe we can also have a less-conveniently-named value that actually turns off scrollbars all the time, which makes it clearer what the author's responsibilities are.

Well, that seems a bit complicated, but I guess I could tolerate that outcome if that's what can get consensus.

[alexelias]

In the event that we decide to go with the 2 different disabling values, it raises a new bikeshed. In naming these, we should keep in mind the primary use cases we each have in mind, to pick names that will appeal to each type of dev:

• Your opinionated value would be useful for aesthetic touchscreen cases, such as infinite scrollers (where the overlay scrollbar moves chaotically and provides little useful information), or edge-to-edge image scrollers. We could call it hide.
• My predictable value would be most useful for custom scrollbar implementors. We could call it custom, replacement, or manual.

[RByers]

So now that #92 is resolved, is there a plan for hiding scrollbars completely? This is one of the main use cases for -webkit scrollbar styling in blink (it's possible we'd be willing to drop that feature if we had a standard solution to disabling UA scrollbars).

/cc @frivoal @tabatkins @atanassov

[frivoal]

So what we want is:

• No visible browser-provided UI
• layout/painting identical to overflow:hidden (probably including the interactions with scrollbar-gutter)
• Desipte the lack of visible scrolling UI, the element reacts any kind of user activated scrolling, such as panning on a touch screen, two-finger scrolling on a touchpad, scrollwheels...

Right?

I don't think this belongs in the scrollbar-gutter property. Maybe it could go into overflow, but I am not 100% sure what to call it there. Another alternative might be scrollbar-style: auto | manual.
I'm calling it manual rather than none as a hint to authors that this is meant to let them manually provide the UI they want, rather than as a mean to have no UI at all, but the behavior is the same.

From there, we could:

• add a scrollbar: <scrollbar-gutter> || <scrollbar-style> shorthand
• potentially add more values later scrollbar-style: auto | manual | overlay | classic | bunch-of-dots

[tabatkins]

@alexelias

The main use I have in mind is precisely developers who want to manually provide an alternate scrollbar affordance (e.g. contact list big-letter scrollbar). Your proposal raises the risk of double-scrollbar glitches, then. You'd be forcing webdevs to detect whether the UA scrollbar is present or not in order to disable their superior bespoke scrollbar...

No, if you're providing an alternate scrollbar you'd just use overflow:hidden. The whole point of an alternate scrollbar is that it's controlling scrolling via JS, so there's no need for anything else.

Unless you want an alternate scroller for everyone, and allow panning-friendly devices to scroll in their normal way with UA-provided scrolling? With, I suppose, a passive scroll listener to update the alternate scroller as well? I could get down with this, I guess. Naming something like replacement might help communicate what it's intended for, and reduce random usage.

[alexelias]

No, if you're providing an alternate scrollbar you'd just use overflow:hidden. The whole point of an alternate scrollbar is that it's controlling scrolling via JS, so there's no need for anything else.

I think this would be really bad UX even on desktop. Mousewheel, trackpad, keyboard, selection autoscroll, drag-and-drop autoscroll, middle-click autoscroll and scroll-position historyitem restore ought to continue working as normal even if the scrollbar looks different, and each of those is very fined-tuned and basically intractable to reimplement identically in JS.

IMO, the best practice is that every element supporting some variation on scrolling ought to be marked overflow: scroll, even if it scrolls unconventionally in certain respects. overflow: hidden is best reserved for use cases that are completely non-scrolling-like.

Unless you want an alternate scroller for everyone, and allow panning-friendly devices to scroll in their normal way with UA-provided scrolling? With, I suppose, a passive scroll listener to update the alternate scroller as well?

Right, this is what I have in mind (panning, and every other non-scrollbar modality should keep working). I'm fine with the name replacement.

[Yaffle]

How to implement a single line text editing contenteditable with hidden, but scrollable content? (like <input type=text />)

[tantek]

The new CSS Scrollbars 'scrollbar-width' property with a value of 0 (or 'none' if we go that route), has the requested effect for this issue.

<https://drafts.csswg.org/css-scrollbars-1/#scrollbar-width>

That is, hidden scrollbars, but content remaining scrollable.

label: #css-scrollbars-1

(Originally published at: http://tantek.com/2018/190/t2/)

[jonjohnjohnson]

How to implement a single line text editing contenteditable with hidden, but scrollable content? (like <input type=text />)

@Yaffle, here is a specified way to achieve the desired result:

el {
  white-space: nowrap;
  overflow-inline: scroll;
  scrollbar-width: none;
}

But afaict from the title/op, this issue can be closed. Then we can move other panning/style scrollbar ui discussions for other/new filings.

[frivoal]

This functionality has been added through scrollbar-width: none. Closing.