We've heard a bunch of feedback from web developers that they want this feature (eg. it makes it easier to reason about layout when content grows/shrinks in an overflow:auto container). So we do not plan to deprecate this API from blink.

A great addition to the overflow spec. Implementing the -ms- feature we were concerned that the overlay scrollbars on top of the content degrades reading experience quite a bit, thus the autohiding behavior.
What are you proposing that we standardize?

The cases we've seen developers choose to use overflow:overlay, they're careful to have sufficient padding-right such that the scrollbars don't actually overlap the content (though I guess this depends on the implementation detail of the default scrollbar width - maybe the spec should define a maximum). So I think that would be OK. Since there's already non-trivial use of this syntax on the web, if we agree the semantics are reasonable, the simplest thing would be to standardize it.

That said, there's additional reason to like the authiding-scrollbar behavior. I don't know offhand if the developers who wanted overflow:overlay would be content with autohiding behavior as the only option. I'd personally be happy standardizing both.

@esprehn, @tabatkins thoughts?

First, one process oriented comment. The CSSWG uses the www-style mailing list for technical discussions, not github. That may change one day, but so far it hasn't, so we should bring this back to the ML.

Now, on the proposal itself.

Regardless of whether we use autohiding or not or both, I think using the overflow-style property makes more sense:

• Better graceful degradation. In a UA that doesn't support it you still get the correct value for the overflow property, which wouldn't be the case if we used overflow:overlay which would fallback on the default value, most likely visible.
• If you want to apply the same overflow style to many scrollers, it's much easier to get this to cascade separately:

* { overflow-style: overlay;}
#foo { overflow: auto; }
#bar, #baz {oveflow: scroll}

We have conversations in other venues about technical topics all the time, so I think it's fine to continue to discuss this here. The only requirement I'd like to have is that a summary be posted to www-style with a link back here. I'll bring this process detail up in the meetings next week.

Sure. I just mean that while IRC discussions and the like are understood by all as being informal, some groups actually do use github for decision making but not this one, so there is potential for confusion. As you say, as long as it comes back to www-style at some point, it's all good.

For WebKit I don't think we want authors to be able to force scrollbars to diverge from the system-wide behavior. overflow: overlay is a historical artifact added for a Safari feature many years ago (before the system had overlay scrollbars), and I don't really want to see standardized.

@smfr Does iOS currently use overlay scrollbars by default? Or layout-affecting ones?

iOS uses overlay scrollbars exclusively.

So if we specced this as hinting that the author wants overlay scrollbars (without implying that the default has to be non-overlay), I assume you'd be cool with it?

Is any UA willing to allow authors to change the types of scrollbars in different scrollable areas on a page?

We do that today, with overflow: overlay, thus this thread asking for it to be specced. ^_^ IE has something similar. Check the first post.

In Sydney we discussed that it's probably not really the overlay property devs want but these two sub-properties:

1. No layout changes on size changes (like overflow:scroll)
2. No (ugly) visuals when scrolling isn't needed (like overflow:auto)

Could these properties be achieved without dictating anything that contradicts system appearance, and without introducing the "may cover content" (or "hard to grab with mouse") concern?

Eg. Maybe something like overflow:auto but that adds scrollbar-sized padding when no scrollbars are shown?

This sounds legit to me. Identical to overflow:scroll, but without actually drawing any scrollbar. +1

Wanna take this to the list for wider comment?

I'm happy to do that, but just before we do: if that's really what we want so we need a new API for it at all? I.e. is it possible it's web compatible to either stop drawing the disabled scrollbars for overflow:scroll? In what situation would a developer want to be able to request overflow:scroll instead of this new behavior?

There's absolutely zero page-observable difference between "draws the disabled scrollbars" and "reserves space but doesn't draw anything". So yeah, it's completely web-compatible. You wanna do that in Chrome, then we can add some text to the Overflow spec recommending that?

What if the page puts something there (e.g. abspos) with a click event handler? Seems observable.

Seems unlikely to be a problem, though. Also, you can make that area behave exactly the same as a transparent scrollbar, in which case it would be completely unobservable.

@smfr I assume you mean, like, underneath it, so the click event hits the element when it would otherwise have been intercepted by the disabled scrollbar?

If so, I agree with fantasai on both counts.

If I understand correctly, the current proposal is to have overflow: overlay reserve space for a scrollbar, only draw that scrollbar if it's "active", and intercept hit testing in the scrollbar region as if it were visible.

I think this defeats the purpose of overlay scrollbars. The whole point is to not take up any space, leaving more space for content. And for many types of content, it's just fine to paint in the area under the scrollbar (which is invisible most of the time).

The main problem comes with putting interactive content in that scrollbar area, like small buttons, where attempts to interact with the button end up bringing up the scrollbar. On Mac, at least, this is ameliorated by only showing the scrollbars when two fingers are on the trackpad, or you actually start to scroll.

No, what Rick suggested just above is that we start by just saying that overflow:scroll is allowed to just... not paint the scrollbars if they're disabled. Keep the space, but don't draw anything. This should be a no-op for pages, but make overflow:scroll less ugly, and satisfy at least one major use-case for "overlay scrollbars".

Whether or not that space intercepts hit-testing is an open question that I think is relatively unimportant. We should decide one way or the other when speccing it (or make it explicitly undefined and encourage browsers to experiment and report back), but it's not a vital question to answer while evaluating this option.

For content that's okay with the scrollbars overlapping, we can then talk about actually speccing overflow:overlay. But this minor edit to scroll is actually safer and arguably more commonly useful, and gets us what we want without having to worry about "platform conventions" getting in the way.

I think this defeats the purpose of overlay scrollbars. The whole point is to not take up any space, leaving more space for content.

I strongly disagree. That's one point, yes, and if that's the goal you need true "overlay" scrollbars. The other reasons for this kinda thing, though, are to prevent your layout from shifting based on whether or not a scrollbar shows. For this it doesn't matter whether there's some lost space on the side or not; you can adapt either way, you just want it to be stable. overflow:scroll does that today, but at the cost of having an ugly disabled scrollbar when the element isn't scrollable, which is enough of a downside that people actively avoid that value and instead hack around overflow:auto. So we can just fix that downside.

And if we do that, we can be more aggressive about designing features that treat overflow:auto as always not having scrollbars, like vw and friends do, because people can then just use overflow:scroll if they want that space reserved. (Or overflow:overlay if/when we spec that.) Simpler layout code, yay!

We discussed this a bit for blink and people pointed out that it's very common to have full-width content that would look weird if it didn't go to the edge of the container (see screenshots here). Since we can't automatically determine if the content is "background" (safe to overlap with a scrollbar when present) or essential UI, we can't just automatically do the right thing.

Yeah, I suppose I agree, unfortunately. :/

So we're back to needing new values to opt into good behavior, and never ridding ourselves of the terrible "overflow: auto" effect on layout calculations unless/until everyone agrees to switch to overlay scrollbars.

Right, but I don't think the correct thing is new values to the overflow property, but rather values to an overflow-style property.

• The fallback behavior in UAs that don't support this is better
• These things cascade separately
• Whether something has scrollbars or not (overflow: auto / scroll vs visible / hidden) is an independent question of how the scrollbars should look like.

I can also see Apple's point that authors should not have control over this at all. But if they should, I'm pretty sure it shouldn't be in the overflow property.

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.

I'm confused - what part of this isn't already done by overflow:hidden? If you're just script-scrolling, overflow:hidden works just fine.

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'm confused - what part of this isn't already done by overflow:hidden? If you're just script-scrolling, overflow:hidden works just fine.

These scenarios are explicitly about avoiding script-scrolling (that's got a number of drawbacks, although it's commonly used for these scenarios).

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.

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?

Good point, though it's not just "touch" devices - you can still scroll with a mousewheel etc.

If it's vertical, yeah. You explicitly mentioned a horizontally scrollable strip, tho. ^_^

We want to support those scenarios as native scrollers right?

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.

For example, a "panning" overflow-style could hide the scrollbars when the device is capable of panning, and default to showing scrollbars otherwise.

Or this could be Media query based.

MQs let authors vary styles. I'm not sure how they help us define default behavior of a value.

Sure. I'm just saying that showing scroll-bars when you have a mouse and have them invisible (not autohide) when you're on a panning device may not be a sufficiently common desire that we need to have a built in value to handle it, and if authors can use MQs to figure out they're on a device with panning, they can do it themselves.

Just realized / remembered another aspect of overflow:auto which sucks when the overflow-style isn't overlay: vertical scroll bars aren't taken into account for inline intrinsic sizing (cause they can't):

pre {
    max-height: 100px;
    overflow-y: auto;
    width: max-content; /* or width: min-content,
                           or float:left
                           or position:absolute
                           or <td><pre>...</pre></td> */
}

This gives you a horizontal scrollbar in addition to the vertical one when there's vertical overflow, which is not what the author wants (typically). This wouldn't:

pre {
    max-height: 100px;
    overflow-y: auto;
    overflow-style: overlay;
    width: max-content; /* or width: min-content,
                           or float:left
                           or position:absolute
                           or <td><pre>...</pre></td> */
}

Proposal:

Name: overflow-style
Values: auto | auto-hide | overlay
Initial: auto;
Applies to: same as the overflow/ overflow-x / overflow-y properties
Computed value: as specified
Animation type: discreet

auto: scrollbars, if present, are drawn according to platform conventions.

overlay: scrollbars must not consume space. The UA should follow platform conventions as to the appearance of the scrollbar, but it must also make sure that underlying content remains visible, for example by making scroll bars transparent, or by automatically hiding them when the use is not actively scrolling.

auto-hide: For scrollbars caused by overflow: auto, this does the same as overflow-style :overlay. for scrollbars caused by overflow: scroll:

• the UA must reserve space for the scrollbar to ensure that it does not overlap with content.
• the UA must follow platform conventions as to the appearance of the scrollbar. Depending on platform conventions, the UA may make the scrollbar invisible when the use is not actively scrolling. If the scrollbar is transparent, or partly transparent, or sometimes invisible, the area under it is painted as if it were an extension of the padding area.
• If the scrollbar would be non-operable due to the element having no overflowing content in the relevant dimention, the UA must not display the scrollbar, but it must still consume reserve the same amount of space. This area is painted as if it were an extension of the padding area.

The goals with the suggestion above is double:

• give authors all they need: both the ability to opt into scrollbars that don't take space, and into scrollbars that do take space but don't look ugly when there's no scrolling to do, while at the same time also
• All browser vendors to match continue to match platform conventions. On platforms that have overlay scrollbars by default: the native appearance is always preserved, and the property only changes whether the scrollbar also takes space. In Platforms that have non-overlay scrollbars by default, the appearance is preserved for the auto and auto-hide values in all cases, and if the platform also has (opt-in) overlay scrollbars, it uses that appearance for overlay as well.

I think overflow: auto-hide should behave the same for overflow: scroll and overflow: auto when there is sufficient content to scroll.

If the width of the scollbar is known to CSS an author could write,
margin-left: max(1em, --ui-scrollbar-width)
or whatever, and reserve space accordingly. That might be better than a new property.

The main difficulties I see is are

1. you don't know whether the scrollbar will be on the left, right, top, bottom, depending on language writing mode and user locale and preferences.
2. the box model needs to be clear that the scroll bar comes out of margin (or padding) space. Maybe that's already clear?
3. we don't actually have max()

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

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.

Oooh, or, since at least Chrome/WebKit already have the overlay value, define that it's an alias of value1, and deprecated.

Now that this property is just about reserving space, I don't think " overflow-style" is a good property name. It's more like "scrollbar-gutter: auto/when-scrollable/always;"

Dang yeah, that's pretty good. Tho overflow-gutter just to keep it under the overflow umbrella. And maybe stable instead of when-scrollable (which is both long and a little difficult to spell).

This all sounds great, but I'd like to also reopen @rbyers's earlier request to including a way to hide overlay scrollbars entirely and reserve no space. 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.

Now that this property is just about reserving space, I don't think " overflow-style" is a good property name.

I agree.

It's more like "scrollbar-gutter: auto/when-scrollable/always;"

Dang yeah, that's pretty good. Tho overflow-gutter just to keep it under the overflow umbrella.

Then again, overflow-gutter (or overflow-style for that matter) incorrectly suggests that this may be a longhand of overflow. So maybe we're better off without an overflow prefix.

And maybe stable instead of when-scrollable (which is both long and a little difficult to spell).

Agreed. I had been looking for names for your value1 and value2, and also landed on stable for value1. And if the property is called ...-gutter, always is pretty good for value2.

I'd like to also reopen @rbyers's earlier request to including a way to hide overlay scrollbars entirely and reserve no space [... but not the same as overflow:hidden, because it would still respond to the scroll wheel or touch panning ...]

I have no strong opinion for or against this part, but if we want it, it feels like it would influence the property and the other values' names. hidden or invisible sounds like an OK name for this value3, but not under a property called ...-gutter. And since that part of the name was what made it possible to call value2 always, if we do want this value3 we have a bit more bikeshedding to deal with.

scroll-style: auto | stable-gutter | always-on-gutter | no-scrollbar Meh, that's lousy.

Also, I am not sure what that implies in terms of bikeshedding, but other than auto, all these values make overflow:scroll and overflow:auto identical to each other. Maybe overflow:auto should never have existed, and we should have had overflow:scroll; scroll-style: on-demand instead. But that ship has sailed a looooong time ago.

Since it sounds like we're converging on some gutter-defining API, I split the "mechanism for disabling scrollbars" debate off into #419.

Bikeshedding a bit more, I think I like:

overflow-gutter: auto | stable | always

(and none if we end up accepting #419)

All of these values only have effect when overflow is auto:

• auto would give us today's behavior (or, if it turns out we can change it, act like stable)
• stable is the "zero space if overlay, always space if intrustive" behavior
• always is the "always space as if it's intrusive, even if you have overlay" behavior

If people don't have objections to these, I'll write them up proper in a spec.

Rather overflow-gap to match grid-gap and multicol-gap?

Hahaha, yeah, sure.

It's actually a substantially different concept--more like the gutters used for bookbinding, not really a gap between things. So gutter seems better imho...

Whether we call the the property -gutter or -gap, the three value version (auto | stable | always) seems good to me.

Adding none if we end up accepting #419 seems a little bit weirder. It suggests we don't have a gap/gutter,
when what we don't have is a scrollbar. That said, while I find it a bit odd, I wouldn't object.

@fantasai Even if the concept is a bit different (I agree, it is), it's close enough that converging on names is worthwhile. The semantic difference between "gap" and "gutter" is razor-thin - this is indeed a gap between the outer edge of the padding box and the inner edge of the border box. I don't like forcing people to remember precisely which way we were leaning in the wind at a given time, even if one can argue that something is slightly more appropriate; better to be consistent and slightly wrong, than inconsistent but completely correct.

@frivoal Yeah, I'm not in any way attached to expressing the "no scrollbar" functionality thru this, I was just pointing out that we have a reasonable name available if we do indeed go that way. It's not part of the current proposal.

I don't actually conceive of this as a “gap” at all: it is filled by the scrollbar. So to me it doesn't even seem close to right.

Bikeshedding aside, following the last conf call, we now have 3 proposals:

1. Have the 3 values (auto/stable/always) attached to a separate property that is not a longhand of overflow. e.g: scrollbar-gutter: auto | stable | always
2. Have the three values attached to an overflow-something property that is a longhand of overflow. e.g. overflow-gutter: auto | stable | always
3. Have the two non default values (stable/always) be optional values directly on the overflow property. e.g. overflow: visible | hidden | scroll | auto [stable | spaced]?

In all cases, if we decide to accept #419 as well, we can add the additional value.

I prefer solution number 1, because it makes sense to me that this would cascade separately (which makes it better than 2 and 3), and also because this seems more robust with regards to dealing with fall back behavior in browsers that don't support this property (which makes it better than 3).

I don't understand why this needs to cascade separately. This isn't an independent piece of behavior - it's modifying the behavior of one value in 'overflow'. Effectively these are just two new 'overflow' values; the argument against actually doing that is that 'overflow' is already overloaded in handling multiple overflow-related things, and adding more values here would just increase the confusion.

In other words, there's no reason for the user to set "overflow: auto" if they really want the stable/always behavior. It doesn't offer them anything additional; it doesn't make their life easier for some other reason. They should just be setting the "stable" or "always" value directly on those elements, and only use "auto" if they actually want "auto" behavior.

Whether or not something needs a scrollbar to show up when there's overflow is something you need to decide on an element per element basis.

What that scrollbar should look like is something that you may sometimes want to decide on an element per element basis, but you may also want to make page-wide (or widget-wide, or component-wide... .i.e non local) decisions, and that's a lot easier to do if they cascade separately. And it gives better fallback behavior when some values are not supported: auto is a better fallback from stable than visible, which is what you'd get if you're not careful.

Based on that, I think that it makes sense for the values we are discussing now to be in a different property than the choice between visible vs auto. By that logic, it could make sense for the choice of scroll vs auto to be in that same other property as well, but too late for that.