[css-overflow-3] Standardize `overlay` as a synonym for `auto`

[chrishtr]

WebKit-ancestral browsers (including Blink) at one point implemented a non-standard overlay value for scrolling.This was never standardized (see here for a discussion of why it shouldn't be).

Subsequently, WebKit made overlay a synonym for auto .Gecko treats it as an invalid keyword. Blink still retains the original implementation (but the change to match Webkit is tracked in this bug).

This also came up as a compat problem in Interop 2023 discussions.

I propose to put the current WebKit behavior (overlay is an alias to auto) into the spec as a web compat compromise, because making it invalid would likely break too many sites.

[Loirooriol]

I think it would be quite confusing to accept overlay but then use classic scrollbars. It could also be a problem for webpages that are using CSS.supports("overflow", "overlay") to decide whether to polyfill overlay scrollbars or try to use a native approach.
Would the breakage of removing overlay be that bad, given that Gecko doesn't support it?

[tabatkins]

That polyfill test would already fail in WebKit, per Chris's comment about their behavior.

I'm surprised Gecko can get away with overlay being invalid, since if there's no backup value it defaults to visible which is very different, but maybe it's the case that due to Firefox, enough sites set overflow: auto; overflow: overlay;. Or maybe those pages are just broken in Firefox. :/ It would be good to see if we could indeed get away with just killing it, tho.

[jgraham]

Firefox doesn't really get away with this; it's a pretty significant webcompat issue, which is why we're keen to get something fixed here; see https://bugzilla.mozilla.org/show_bug.cgi?id=1521631 for details (all the See Also links are site breakage).

That bug has a patch to alias to overflow: auto, but there was a concern that this doesn't work as well on non-mac platforms which don't always have overlay scrollbars cc @emilio

[emilio]

Aliasing to auto seems better than the status quo for us, that's for sure. If blink plans to do it we're more than happy to do so as well.

[Loirooriol]

AFAIK the problem with overflow: overlay is that for now there is no implementation interest to have a feature to allow authors to choose overlay scrollbars. If this changes in the future, but now we define overflow: overlay as auto, then authors won't be able to use @supports to check whether they can choose overlay.

[chrishtr]

If this changes in the future

I don't think it will change in the future. We generally resolved that the choice of overlay or non-overlay scrollbars is a user/UA/OS setting, not a developer setting.

[emilio]

What I didn't realize at the time of reviewing @jwatt's patch for Gecko is that Safari apparently does support non-overlay scrollbars (based on OS settings).

So if WebKit is already providing overflow: overlay as classic scrollbars in that case, seems like aliasing to auto is even more palatable.

[emilio]

@fantasai I'd like to prioritize this if possible, just to confirm that aliasing to auto should be fine. I believe this should be simple enough, wdyt?

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow-3] Standardize `overlay` as a synonym for `auto` , and agreed to the following:

• RESOLVED: overlay is legacy value alias for 'overflow: auto'

The full IRC log of that discussion

<fantasai> scribe+
<fantasai> emilio: Was skeptical at first, because I thought only Safari had overlay scrollbars
<fantasai> emilio: but also have classic scrollbars in OS preferences
<fantasai> emilio: so I think aliasing to auto is better
<fantasai> emilio: chrome folks also wanted to do it
<fantasai> emilio: helpful for compat
<fantasai> emilio: only annoyance is it doesn't do what it says
<fantasai> emilio: but we already discussed that tweaking overlay vs non-overlay should be user choice, not author choice
<fantasai> astearns: smfr, anything to add about aliasing 'overflow: overlay' to 'overflow: auto' ?
<fantasai> smfr: I'm in favor. We agree that it should be user choice rather than author choice
<fantasai> smfr: overlay vs non-overlay escaping onto the Web was a mistake
<fantasai> astearns: Proposed to specify 'overflow: overlay' as alias
<fantasai> fantasai: legacy name alias?
<fantasai> emilio: Yeah, I think that would be best
<fantasai> https://www.w3.org/TR/css-cascade-5/#legacy-name-alias
<fantasai> s/legacy name alias/legacy value alias/
<fantasai> https://www.w3.org/TR/css-cascade-5/#value-aliasing
<fantasai> RESOLVED: overlay is legacy value alias for 'overflow: auto'