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.

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.

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

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