[css-env-2] env(scrollbar-inline-size)

[argyleink]

Scrollbars are a system provided, dynamic, and out-of-developer's control component that can "get in the way" by consuming unpredictable amounts of space. It'd be nice if the platform provided an environment variable that held the contextual system width value for scrollbars so that developer could use calc() to mitigate unpredictability.

I've gently proposed using logical property syntax for the env variable name, since I feel this is the language used to talk about sizing on the web:

env(scrollbar-inline-size)

Here's a great bad example of how folks are working around this today:
(aka, negative margins)

var checkScrollBars = function(){
    var b = $('body');
    var normalw = 0;
    var scrollw = 0;
    if(b.prop('scrollHeight')>b.height()){
        normalw = window.innerWidth;
        scrollw = normalw - b.width();
        $('#container').css({marginRight:'-'+scrollw+'px'});
    }
}

All in all, having access to the scrollbar width would give folks the values they need to gracefully handle the dynamic aspects of scrollbars with just CSS.

I assume there's aspects to this work that overlap with custom scrollbars, so this env var would need to be a property that can update at runtime yeah? Help me think out the rest of the fringe edge cases, as well as use cases where scrollbar width would be super helpful in your layouts/ui. Thanks!

[jensimmons]

This is related to #4329.

Basically, whatever solutions we come up with in the vertical direction will also be applied in the horizontal direction.

We discussed these issues today at the CSSWG face-to-face in A Coruña. Scrollbars are similar to keyboards. And yes, we were settling on env() variables for the dynamically changing measurements (and not another option). There are pros & cons, usecases & objections.

[emilio]

The scrollbar size can be controlled by the user, so probably should be native-scrollbar-inline-size or something like that.

I presume this is not meant to be element-dependent, right? env(native-scrollbar-inline-size) would be the same regardless of the element having scrollbars or not... right?

[cbiesinger]

This was also discussed today at the CSS F2F as part of #4674

[jonjohnjohnson]

Something like env(scrollbar-width) that is the initial length or length computed from the auto value of the scrollbar-width property?

#2630 (comment)

[fantasai]

Relevant F2F minutes: https://lists.w3.org/Archives/Public/www-style/2020Feb/0007.html & https://lists.w3.org/Archives/Public/www-style/2020Feb/0011.html

[bramus]

With [css-overflow-4] scrollbar-gutter making it possible to prevent unwanted Layout Shifts caused by scrollbars, what does the future of env(scrollbar-inline-size) look like?

I mean, getting the size of the scrollbar is handy, but as we can achieve the same behavior with scrollbar-gutter: stable both-edges;, do we still need env(scrollbar-inline-size)?

/* Keep content centered by manually offsetting the padding-inline-start */
.keep-content-centered-using-envvar {
  padding-inline-start: env(scrollbar-inline-size);
}

/* Keep content centered using scrollbar-gutter */
.keep-content-centered-using-scrollbar-gutter {
  scrollbar-gutter: stable both-edges;
}

Or are there any other use-cases for env(scrollbar-inline-size) besides keeping things visually centered?

---

Also note that manually taking env(scrollbar-inline-size) into account can reproduce funky results when combined with scrollbar-gutter: stable both-edges;:

/* This looks is a bad combination to do, as you'll end up with a double gap at the edge opposing the scrollbar */
.bad-combination {
  padding-inline-start: env(scrollbar-inline-size);
  scrollbar-gutter: stable both-edges;
}

[Schepp]

I still have a use-case and that is when making elements horizontally break out from their parent elements, extending them back to the full available viewable area + combined with programmatic scrolling.

This is the pretty much standardized™ example code to make child elements extend back to full width, regardless of their parent's width (imagine a hero image in an article):

:root {
  overflow-x: hidden;
  overflow-y: scroll; /* could also be done with scroll-gutter */
}

.outer {
  width: 100%;
  max-width: 40rem;
  margin: 0 auto;
}

.inner {
  width: 100vw;
  margin-inline: calc((100vw - 100%) / -2);
}

To my knowledge, this is still the way to go to do these types of things when you work with components and you don't know in what type of element the .inner element will end up living (the alternative approaches using CSS Grid don't work well with componentization or rely on subgrid).

But .inner element will now extend below the scrollbar of the root, creating horizontal overflow. This can again be countered by setting overflow-x: hidden on that root. Problem is, you can still scroll programmatically. This gets apparent, once you start scrolling things like sliders or galleries via scrollIntoView() from left to right and then back again.

Here is a demo of that behavior: https://codepen.io/Schepp/full/jOYdQbv
Note how the page jumps horizontally every time you click on "< start" and "end >" in the slider controls (except for the very first time)

Trying to contain scrolling with overscroll-behavior: contain; doens't work either, as this works from inside out, but scrollIntoView() approaches the task from outside in.

Having env(scrollbar-inline-size) available would enable us to fix that unwanted (programmatic) scrolling by changing our code as follows:

.inner {
  --viewable-area: calc(100vw - env(scrollbar-inline-size));
  width: var(--viewable-area, 100vw);
  margin-inline: calc((var(--viewable-area, 100vw) - 100%) / -2);
}

PS: In theory, one could also trigger page jumping by focusing something close to the right border of the page, and then again something close to the opposing border.

[Schepp]

Okay, so the so far unknown to me overflow: clip seems to be the solution to all my problems 🥳

If you apply this to e.g. <body>, instead of overflow: hidden, it stops programmatic horizontal scrolling of it, when children extend beyond its width (being 100vw - scrollbars):

body {
  width: 100%;
  overflow: clip;
}