I believe overflow:overlay isn't actually web exposed. IIRC it was used just in dev tools.

overflow:overlay is web-exposed and different from auto:

https://output.jsbin.com/qujivoy

It gives you the advantages of overlay scrollbars (no relayout) on all platforms. But you have to add padding to avoid obscuring your content.

I agree it is weird and we should probably get rid of it.

There is some related discussion in  issue 589524 .

(This is also discussed in  issue 554361  and https://github.com/w3c/csswg-drafts/issues/92.)

We can't get rid of this. It's useful and also used in real content, ex. The chrome internal pages use it. We should probably WontFix this. :)

The chrome internal pages no longer use this (to be more precise, they haven't bothered to remove it from their css, but it no longer does anything and could be removed without any effect).

So how's about we add an UMA stat for overflow:overlay and see what we're dealing with?

I don't think we should remove it. The feature is actually useful (and important for some use cases), and without shipping an alternative you force developers to do worse things.

That's how we ended up using it on Downloads. scroll vs non-scroll has a different content width, which means the cards are centered differently. Are you sure it doesn't do anything now? If you only have 1 download vs enough downloads to scroll, and you use overflow: auto vs overlay, are the cards still centered under the search box at the top which is inside a box without scrollbars?

ex. http://output.jsbin.com/riyefupolu

Without overflow: overlay the content is shifted by 16px, which unaligns things.

Apple has been very explicit in their opposition to a value that forces overlay scrollbars; this value won't ever be compatible across the web unless that changes.

The correct answer is to implement the new values discussed in <https://github.com/w3c/csswg-drafts/issues/92#issuecomment-249163456> as soon as they're approved and I put them in a spec, and then move anything internal off of 'overlay' and see about killing it entirely.

Yeah that sounds like a great plan. We just need to provide the alternative before removing this. :)

Re #7: You'll need "overflow-gutter: none" to get the effects of "overflow: overlay", right?  It's not just for https://github.com/w3c/csswg-drafts/issues/419.  Or am I misunderstanding how it works...

downloads still uses overflow: overlay and it still seems to have an effect

https://cs.chromium.org/chromium/src/chrome/browser/resources/md_downloads/manager.css?q=%22overflow-y:+overlay%22&sq=package:chromium&dr=C&l=43

There's only one place with overflow:overlay on downloads, it's basically this:

<downloads-manager style="display: flex; flex-direction: column; height: 100%;">
  <downloads-toolbar style="min-height: 56px;"></downloads-toolbar>
  <iron-list style="overflow: auto;">
    <downloads-item />
    <downloads-item />
    ...
  </iron-list>
</downloads-manager>

So, the downloads-manager will not overflow unless the window is sized smaller than 56px.  It's the iron-list that adds the scrollbar, and it's overflow:auto.

Go ahead an open in up in the inspector, and trying removing overflow:overlay on the downloads-manager.  Nothing happens.

Are you looking in the right version of chrome, that doesn't look right.

https://cs.chromium.org/chromium/src/chrome/browser/resources/md_downloads/manager.html?q=downloads-list&sq=package:chromium&dr=C&l=23

    <iron-list id="downloads-list" items="{{items_}}"
        hidden="[[!hasDownloads_]]">

https://cs.chromium.org/chromium/src/chrome/browser/resources/md_downloads/manager.css?type=cs&q=%22overlay%22+file:downloads&sq=package:chromium&l=40

#downloads-list {
  /* TODO(dbeam): we're not setting scrollTarget explicitly, yet
   * style="overflow: auto" is still being set by <iron-list>'s JS. Weird. */
  overflow-y: overlay !important;
}

Oh, you're in stable 52.0.2743.116 which incorrectly sets it on it on the manager. That was fixed long ago, you definitely want to be looking at Canary and not stable. :)

54.0.2837.0 (Official Build) dev (64-bit)

Yeah, I think there was a mistake made, it was fixed here:
https://chromium.googlesource.com/chromium/src/+/ffabcb7320d61727b552d23999d82f8aa40ed2ad%5E%21/#F2

In any case it definitely does do something. If you remove it the search box is not centered over the cards when there's a scrollbar.

so what's the story here?  i want to use overflow-y: overlay on md-settings as well (fixes the same centering problem as on downloads)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0527e2bfcc1847ed80e3ddd6c0b25cbcc555b4b9

commit 0527e2bfcc1847ed80e3ddd6c0b25cbcc555b4b9
Author: dbeam <dbeam@chromium.org>
Date: Thu Sep 29 22:53:41 2016

MD Settings: use overflow: overlay for better centering

This makes the scrollbar render on top of the content, rather than push
it aside when theres too much content.

BUG=649496
R=dpapad@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2379933003
Cr-Commit-Position: refs/heads/master@{#421965}

[modify] https://crrev.com/0527e2bfcc1847ed80e3ddd6c0b25cbcc555b4b9/chrome/browser/resources/settings/settings_ui/settings_ui.html

Current proposal is to add scrollbar-gutter to control this behavior instead.
scrollbar-gutter: auto | [ [stable | always ] ]

See https://github.com/w3c/csswg-drafts/issues/92

Once the spec for that has stabilized and we have an implementation we can start thinking about deprecating overflow:overlay.

eae@: awesome!  let us know and we'll be happy to switch over.