[css-overflow] overflow: Consider reserving space for scrollbars with some property

[RByers]

WebKit/blink have "overflow: overlay" to enable scrollbars that don't take up layout space. Back in 2013 Tab said he supported standardization of this.

IE/Edge has '-ms-overflow-style: -ms-autohiding-scrollbar' which does the same but also indicates that scrollbars should automatically hide when not in use. Note that many sites try to implement this themselves today based on mouseenter/mouseleave events, which breaks touchscreen scrolling.

I don't know all the history here, but does CSSWG want to consider standardizing something here?

This bug tracks potential removal in blink.

[RByers]

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.

[atanassov]

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?

[RByers]

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?

[frivoal]

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}

[astearns]

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.

[frivoal]

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.

[smfr]

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.

[tabatkins]

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

[smfr]

iOS uses overlay scrollbars exclusively.

[tabatkins]

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?

[smfr]

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

[tabatkins]

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

[RByers]

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?

[tabatkins]

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?

[RByers]

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?