Intent to Prototype: CSS Overflow scrollbar-gutter

[Felipe Erias Morandeira]

Contact emails felip...@gmail.com Explainer https://github.com/felipeerias/scrollbar-gutter-explainer Design docs/spec Specification: https://www.w3.org/TR/css-overflow-4/#scollbar-gutter-property TAG review https://github.com/w3ctag/design-reviews/issues/520 Summary The "scrollbar-gutter" property provides control over the presence of scrollbar gutters (the space which may be reserved by the UA to display a scrollbar). Motivation This property provides authors with more control over how their layouts interact with the scrollbars provided by the UA. For example, authors will be able to prevent excessive layout changes when their content expands, while avoiding unwanted visuals when scrolling isn't needed. The presence of the scrollbars themselves is still controlled by the "overflow" property. When a gutter is being displayed but a scrollbar is not, the gutter will be painted as an extension of the padding. Risks

Interoperability and Compatibility The syntax for scrollbar-gutter may still evolve based on CSSWG discussion. Mitigation: defer shipping until syntax has stabilised. Firefox: No public signals Edge: No public signals Safari: No public signals (https://bugs.webkit.org/show_bug.cgi?id=167335) Web developers: Positive (https://github.com/w3c/csswg-drafts/issues/92)

Long discussion of scrollbar-gutter at the CSSWG, citing developer need for an easier way to reason about layout when content grows or shrinks.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? Not yet. Tests will be added as part of this implementation. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5746559209701376

Tracking bug

https://crbug.com/710214

[Philip Rogers]

I'm happy to see progress on this! This feature is useful for developers and will let us clean up our non-standard overflow: overlay code.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/248965c0-94a3-4acb-b713-2bcb9db49f4ao%40chromium.org.

[Christian Biesinger]

I agree this is a very useful feature and it's fine to prototype but I
think there needs to be more discussion on the exact shape of this
API. See e.g. the issue I filed on it:
https://github.com/w3c/csswg-drafts/issues/4674

Hopefully some implementation experience can help in shaping the API.

cc fantasai, FYI

Christian

> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJgFLLvjdY1D0vt1_HZy06XCKc-fXnnqnN1Nti1WyEw%3D%3DaFytA%40mail.gmail.com.

[Felipe Erias Morandeira]

Hi,

I saw that issue while researching this feature, thanks for bringing it up.

My understanding is similar to yours: this is a use case that is worth solving, but the exact way to do that might still be subject to change. I’ll be happy if my work helps us get there.

Best regards,

Felipe

[PhistucK]

Will this solve the problem of centering across sections where some have a scroll bar and some do not (while still having appropriate padding, unlike overflow: overlay)?

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFvyC9BnAynASFz6XssrBS9X18Vd2hkeViG3QOzCkzTTxB35Ug%40mail.gmail.com.

[Felipe Erias Morandeira]

That is one of the goals of this feature, yes.

You would be able to:
— reserve a stable amount of space for the scrollbar
— add a symmetric spacing on the opposite edge so the content is centered
— add the same spacings to elements that are not scrollable, like a header

Do you have a specific use case in mind?

Best regards,
Felipe

[PhistucK]

Showing prices in various rows in the main content of the screen (which may or may not have a scroll bar) and the total price in the footer of the screen and have them aligned, kind of like a bill. Something like this -

☆PhistucK

[Felipe Erias Morandeira]

Thank you, that is a very good example.

On the scrolling container, you would use

     scrollbar-gutter: stable both;

This is what would happen with __classic__ scrollbars:

 — "stable": a space would be reserved on the edge with the scrollbar

 — "both": symmetrically, the same space would be reserved on the opposite edge

 — except if/where a scrollbar was being displayed, that extra spacing would look just like an extension of the element's padding.

If the UA used __overlay__ scrollbars, there wouldn't be an apparent effect. If you wanted to reserve the same extra space regardless of whether classic or overlay scrollbars were being used, you would use "always" instead of "stable".

Extending your example a bit: if you wanted the content inside the (non-scrolling) footer to be aligned with that in the scrolling container above it, you would add

    scrollbar-gutter: stable both force;

to the footer's style, so that same amount of space is reserved along both its edges.

I hope that was clear :) There is a visualization of several scrollbar-gutter values in the explainer

  https://github.com/felipeerias/scrollbar-gutter-explainer#illustrations-

And this comment gives more detail about the "force" keyword (with images)

  https://github.com/w3c/csswg-drafts/issues/4674#issuecomment-575027040

Best regards,

Felipe

[PhistucK]

Thank you. Yes, this is pretty clear and helpful (once we drop Internet Explorer 11 support. Oh, my. Yes).

The only (unsolvable) problem is (what looks like) the extra padding (but is really just the "both" effect). I guess the design would just have to change to have the extra padding.

☆PhistucK

[Steve Kobes]

On Tue, 16 Jun 2020 at 07:25, PhistucK <phis...@gmail.com> wrote:

The only (unsolvable) problem is (what looks like) the extra padding (but is really just the "both" effect).

In my opinion - and if my understanding is correct - it is a problem for scrollbar-gutter that the scroller's contents cannot paint anything inside the gutter.  This makes it impossible for example to have a full-width solid-background header, like this gray bar in Monorail:

If scrollbar-gutter: stable were used here, the header would stop short of the frame edge in the scrollbarless state (on a classic-scrollbar platform), leaving an ugly white gap.  There is no way to avoid the gap and still preserve layout stability at the scrollbar-existence transition point.

A solution would be to adopt scrollbar-gutter: none as proposed here.  This would provide layout stability without a gap, and give the developer maximum control.

It is also achievable in Chrome with overflow: overlay, but this option is not standardized and there is a desire to remove it.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_JDdcwck1_xWd353TP3AH_E%2B-5pxs6ggHrUFuYzM5j3PQ%40mail.gmail.com.

[PhistucK]

overflow: overlay (and so will scrollbar-gutter: none) is currently solving our problem and creating another ugly one, we have unequal side padding as a result, so when the right padding is too narrow, the content overlaps with/is a bit obscured by the scroll bar.

☆PhistucK

[Steve Kobes]

On Tue, 16 Jun 2020 at 10:22, PhistucK <phis...@gmail.com> wrote:

overflow: overlay (and so will scrollbar-gutter: none) is currently solving our problem and creating another ugly one, we have unequal side padding as a result, so when the right padding is too narrow, the content overlaps with/is a bit obscured by the scroll bar.

But you can control the padding on inner elements, right?  So just declare a padding that is >= scrollbar width?

[Chris Harrelson]

On Tue, Jun 16, 2020 at 8:36 AM Steve Kobes <sko...@chromium.org> wrote:

On Tue, 16 Jun 2020 at 10:22, PhistucK <phis...@gmail.com> wrote:

overflow: overlay (and so will scrollbar-gutter: none) is currently solving our problem and creating another ugly one, we have unequal side padding as a result, so when the right padding is too narrow, the content overlaps with/is a bit obscured by the scroll bar.

But you can control the padding on inner elements, right?  So just declare a padding that is >= scrollbar width?

 

☆PhistucK

On Tue, Jun 16, 2020 at 4:56 PM Steve Kobes <sko...@chromium.org> wrote:

A solution would be to adopt scrollbar-gutter: none as proposed here.  This would provide layout stability without a gap, and give the developer maximum control.

The conclusion of that issue was that scrollbar-gutter: none is not a good idea, because:

On a browser configuration that does not have overlay scrollbars, content is hidden underneath the scrollbar and the user cannot see it, which is very bad. On configurations that *do* have overlay scrollbars, there is no need for a scrollbar gutter in the first place and layout is stable.

scrollbar-gutter: none also gets in the way of the user controlling which type of scrollbar they want.

Therefore, my plan of record for Chromium is to add support for default overlay scrollbars on all platforms (we already have them on all platforms except Windows and Linux). However, the other values of scrollbar-gutter are still useful to gracefully account for non-overlay scrollbars, which will remain with us for the foreseeable future.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAjAU%3DbiGU%2BBd0GKxRF%2B_ZBN7xY9-Wp0Ykg-Qw5sEqNgocOtyA%40mail.gmail.com.

[PhistucK]

Looks like you are operating under the assumption that the width of the scroll bar is constant everywhere. That assumption is unsound...

(Unless you mean using JavaScript, but that kind of loses the point).

☆PhistucK

[Steve Kobes]

You are right that the web does not currently expose the platform scrollbar width in a declarative way.  It would be great to have that in CSS, like a scrollbar-width unit or something.

[Felipe Erias Morandeira]

Thank you, that is a very good point.

I have opened an issue for it:

    https://github.com/w3c/csswg-drafts/issues/5232

Best regards,

Felipe

[Felipe Erias Morandeira]

Hi,

Just a heads-up that we have found a potential solution for that use case:

https://github.com/w3c/csswg-drafts/issues/5232#issuecomment-648047604

Feedback appreciated!

[Felipe Erias Morandeira]

Hi,

This is a heads-up that the initial implementation of the scrollbar-gutter CSS property has landed in Blink (bug #710214).

The property is the "test" state for now, which means that it is only enabled when performing tests.

As part of this implementation, we have updated the API for computing the scrollbars and scrollbar gutters of a box (LayoutBox::ComputeScrollbars()). 

And as a nice side effect, the switch to the new API fixed an old bug in the DevTools Inspector where the highlight would not match the content when the scrollbar was on the left side (devtools thread).

I plan to continue adding more tests and fixing any bugs that might appear. There are also ongoing discussions at the CSSWG to expand the CSS Overflow spec to cover more use cases.

Feedback and suggestions are very welcome!

Regards,

Felipe