[css-overflow-4] scrollbar-gutter is too complex

[cbiesinger]

https://www.w3.org/TR/css-overflow-4/#scollbar-gutter-property

Blink is interested in implementing/shipping scrollbar-gutter, particularly the "stable" value.

However, the other keywords do not seem as useful. Both "force" and "always" request reserving space even when an overlay scrollbar is used. What's the use case for that? This does not seem useful, and at any rate it is not clear how much space should be reserved.

/cc @bfgeek fyi

[fantasai]

Side comment: this property really ought to be in the scrollbars spec, imho. :/ Even if only in L2.

[frivoal]

force:

force itself doesn't force the creation of gutters with overlay scrollbars (although it can be used together with always, which does). It forces the creation of gutters even if overflow is visible (or clip) if there would be gutters with the other values of overflow. So scrollbar-gutter: stable force would add gutters to overflow:visible elements if the UA uses classic scrollbars, and not if it uses overlay scrollbars. scrollbar-gutter: always force does add gutters to every element

The use case was being able to reserve the same amount of space on the edges of an element that is adjacent to a stroller as is being reserved in the stroller itself, so that things would visually line up. The same effect could be achieved by adding padding for classic scrollbars and none for overlay scrollbars, but there is no reliable way for authors to know if they should be adding that padding, and if so how much.

A concrete example that was given was Gmail (I believe this was raised by Googlers, though I cannot remember for sure), and it's attempt to line up the controls in the toolbar above the list of mails with those in the list of mails. Here are two screenshots from my system (macOS with Firefox), one with classic scrollbars turned on (at the OS level), where Gmail correctly guesses how much padding it should be adding to the toolbar above the list, and one with overlay scrollbars turned off, where Gmail incorrectly adds padding, throwing things out of alignment (orange dotted line added manually to highlight what I'm talking about).

Always:

Always does reserve space for a gutter even on browsers with overlay scrollbars.

This is for cases when authors find the overlap between the overlay scrollbar and the content to be problematic. If the scrollbar ends up being over decorative elements or empty space, it's ok, but if it ends up over text, it can hinder readability, and if over interactive elements, it can get in the way of trying to click those. Overlay scrollbars generally disappear or shrink (or both) when not used, so if the user waits a bit, the content will eventually no longer be obscured, and can be read or interacted with, but this can be annoying.

For instance, something like https://jsbin.com/bulidiv/edit?html,css,output is really annoying to use in a browser with overlay scrollbars. You could add padding to get around that, but (1) how much padding is enough to avoid the overlay scrollbars?, and (2) that padding isn't needed in case of classic scrollbars, so you have to detect that too and remove the padding if you don't want to waste space.

Here's an example at stackoverflow of someone trying to deal with this situation.

---

Anyway, that's what these values are for, and they can be combined because these two use cases aren't exclusive (e.g. https://jsbin.com/kafoyuw/edit?html,css,output).

I think It may be useful to add examples to the spec along the lines of the things I showed here, to help readers understand what this is for.

It is not clear how much space should be reserved.

The spec isn't clear about that, but the intention is that you'd reserve enough space for the overlay scrollbar to fit into when it is displayed. If it has multiple states of varying sizes (on macOS it gets bigger when you hover it), you'd size it to the largest one.

I'm happy to add that clarification.

[css-meeting-bot]

The CSS Working Group just discussed scrollbar-gutter, and agreed to the following:

• RESOLVED: Move scrollbar-gutter to the scrollbars spec, add florian as an editor

The full IRC log of that discussion

<emilio> topic: scrollbar-gutter
<emilio> github: https://github.com//issues/4674
<emilio> cbiesinger: we're interested in implementing this: there's a lot of values for this property, and a lot of values didn't seem that useful to me
<emilio> ... florian came with some use cases but I'm not sure they're useful enough?
<emilio> iank_: we probably only want to implement stable
<emilio> florian: the other values were solving issues raised by google
<fantasai> s/and a lot/but a lot/
<emilio> ... we should explain them better in the spec
<emilio> ... but I'd be sad if we removed it
<myles_> q+
<emilio> cbiesinger: I think your explanation makes sense
<emilio> fantasai: seems to me this feature belongs on css-scrollbars, not css-ui
<hober> q+
<hober> q-
<emilio> florian: don't care, though I'm not an editor of css-scrollbars, so if you want me to keep editing it I should become an editor
<tantek> huh?
<emilio> RossenF2F: objections to move from css-ui to css-scrollbars and adding florian as an editor?
<florian> s/keep editing it/keep editing that feature/
<tantek> sorry I'm joining midconversation so I'm unaware of context
<heycam> from css-overflow, not css-ui
<fantasai> tantek, context is https://github.com//issues/4674
<TabAtkins> tantek, moving scrollbar-gutter to css-scrollbars
<emilio> RESOLVED: Move scrollbar-gutter to the scrollbars spec, add florian as an editor
<RossenF2F> ack myles_
<tantek> thanks fantasai
<emilio> myles_: we did a review with some people that know more about design than me
<emilio> ... this feature fundamentally breaks overlay scrollbars
<emilio> ... but we also understand that there's a real problem here
<emilio> ... and you don't want the scrollbar to cover things
<tantek> myles++ has a very good point
<emilio> ... there's also another issue (#4619) which proposes adding an environment variable with the width of the native scrollbars
<cbiesinger> q+
<emilio> ... it seems that'd allow authors to peek
<emilio> florian: I don't think the stable value changes anything with overlay scrollbars, it's the force value what's problematic for you right?
<emilio> myles_: any property that says "all elements should not be covered by overlay scrollbars" is problematic
<emilio> hober: we like the idea of moving active elements but we don't want to encourage authors to try to inset everything
<RossenF2F> q?
<emilio> cbiesinger: the env variable seems a better case for the google use case
<jensimmons> q?
<jensimmons> q+
<emilio> florian: I don't think it would because an env variable is for the entire page, so it doesn't depend on whether there actually are scrollbars
<emilio> cbiesinger: I meant the combination of the env variable with the stable value
<emilio> fantasai: but florian's point means that scrollbar width may change
<emilio> ... and you don't know the scrollbar width
<cbiesinger> q-
<emilio> myles_: the wide value is not really that wide, so probably just the wide one would be enough
<cbiesinger> s/4619/4691/
<tantek> we deliberately removed explicit numeric width from scrollbar-width. there's also no "wide" value
<tantek> https://drafts.csswg.org/css-scrollbars-1/#scrollbar-width
<cbiesinger> https://github.com//issues/4691
<tantek> just: auto | thin | none
<emilio> myles_: I think the value should be zero for non-overlay scrollbars
<emilio> fantasai: we need both to align non-scrollable elements to scrollbars
<emilio> myles_: isn't that a problem now?
<emilio> florian: yes, but that's something that `scrollbar-gutter` solves
<emilio> ... the `always` toggle let you get the scrollbar gutter on elements that are not scrollable
<fantasai> The example is is a toolbar which is not scrollable over a scrollable box. The author wants the rightmost item in the toolbar to align with the rightmost item in the scrollable box.
<emilio> ... which lets you fix that
<tantek> q+ to ask if Blink also intends to implement scrollbar-color and scrollbar-width? if not, then it doesn't make sense to merge scrollbar-gutter with those properties, because they'll end up blocking each other in CR
<emilio> hober: in a world with that value and non-overlay scrollbars then that'd be zero
<hober> s/non-//
<tantek> there is no "thick"
<emilio> myles_: [[discussing with florian on the whiteboard]]
<tantek> scrollbar-width: auto
<tantek> is what I think people are trying to say?
<emilio> myles_: so you mean that we need two environment variables, one per scrollbar-width value?
<fantasai> The discussion is about how to know how thick to make the padding on the toolbar if the scroller has a 'scrollbar-width: thin' declaration - the solution currently is to say 'scrollbar-width: thin; scrollbar-gutter: always force' on the toolbar
<jensimmons> q-
<tantek> examples?
<tantek> agreed with myles
<emilio> florian: the thing that would fix this is `always`, people are already moving stuff away from the scrollbars, just guessing
<fantasai> s/guessing/guessing how wide they are/
<emilio> hober: so a variable that tells you how wide it is?
<tantek> good I want to hear Jensimmons's thoughts
<emilio> florian: as long as you can do that then I'm fine
<emilio> myles_: there are too many values
<florian> q?
<fantasai> ack tantek
<Zakim> tantek, you wanted to ask if Blink also intends to implement scrollbar-color and scrollbar-width? if not, then it doesn't make sense to merge scrollbar-gutter with those
<florian> q+
<Zakim> ... properties, because they'll end up blocking each other in CR
<tantek> re: https://github.com//issues/4674 "Blink is interested in implementing/shipping scrollbar-gutter"
<emilio> TabAtkins: some of them could be named better
<RossenF2F> q?
<emilio> tantek: I'd like to ask Google which other values besides stable is Blink interested in implementing, and is blink interested in implementing scrollbar-{width,color}?
<emilio> cbiesinger: def. interested in stable and the env variable, not so much in others
<TabAtkins> Okay, so I remember why we did "always" - "stable" means that authors still have to ensure their designs work on both widths. "always" was meant to be a "let authors safely be a little lazier" value.
<emilio> tantek: makes sense, and I tend to agree with myles_ that there's if there's no implementor interest and no use case maybe should be dropped
<emilio> cbiesinger: scrollbar-{width,color} is not on the roadmap
<emilio> iank_: not meaning we won't implement, but not on the roadmap
<TabAtkins> I feel strongly that if we do stable, we *need* force; that's the use-case Florian illustrated and it's very valuable I think.
<emilio> tantek: then I'd probably advocate for undoing the move to the scrollbars spec
<hober> hober: why not put them in different levels of the same spec?
<emilio> ... we'd have to do a lot of gymnastics
<TabAtkins> We can maybe drop "both" - it had use-cases that I think were mostly based on "always".
<emilio> fantasai: I think there's a benefit to have related features in the same spec
<fantasai> s/benefit/benefit to readers/
<TabAtkins> So perhaps an `auto | [ stable && force? ]` grammar reduction.
<emilio> ... keeping it in overflow doesn't make much sense
<emilio> tantek: I don't think there's any benefit of moving it
<bkardell_> what about what hober said?
<emilio> RossenF2F: I don't think we should do busywork just for the sake of doing it, but I do think that we should have scrollbar-related properties together to move them for the REC track, and for readers
<fantasai> hober, scrollbar-color and scrollbar-width already have one implementation
<fantasai> hober, scrollbar-gutter has an intent from Chrome
<emilio> ... this is why we have modules and levels
<fantasai> hober, it's not clear which is further ahead in that respect
<TabAtkins> q+
<fantasai> hober, and we're not even in CR, so there's no reason to drop anything atm
<emilio> RossenF2F: so we probably can still make a level of scrollbars be on the REC track with color/width
<emilio> tantek: given the fact that there's disagreement on what implementors are interested in I think that trumps the cosmetic use case
<bkardell_> "interest" and "priority" aren't the same though
<emilio> ... that practical divergence should override the cosmetic thing
<emilio> fantasai: but it's a WD
<emilio> tantek: right that's why I think busywork is not warranted
<TabAtkins> q?
<emilio> ... hearing from WebKit that they're interested in all three, otherwise just leave it alone?
<emilio> RossenF2F: let's try to avoid discussing process too much... Do you want to undo the previous resolution?
<myles_> q+
<emilio> tantek: yes, because the lack of interest from blink in scrollbar-width/color means we shouldn't do it
<emilio> iank_: that's a misrepresentation
<fantasai> I want to point out that oveflow-4 is otherwise completely experimental stuff and is not an appropriate place for a feature that is being imminently implemented
<tantek> fantasai then move the experimental stuff in overflow-4 to overfow-5
<RossenF2F> q?
<emilio> jensimmons: interest is not the same as saying not on the roadmap
<tantek> don't make extra busy work for multiple specs
<fantasai> tantek, it's not an overflow feature, it's a scrollbar feature
<emilio> iank_: It just meant not in the roadmap at the moment
<fantasai> tantek, it doesn't belong in that module
<emilio> ... that may change in the future
<tantek> overflow and scrolling are tightly related
<TabAtkins> tantek, stop objecting to other people volunteering to do work
<tantek> fantasai quit making an aesthetic argument
<emilio> cbiesinger: I'm more skeptical about the scrollbar width use case, we just don't plan to implement it soon
<fantasai> tantek, it's a usability argument. I want our specs to not be GCPM-style hodgepodgs
<tantek> I'm saying postpone until we get positive signals from implementers for all three properties
<emilio> RossenF2F: there are other implementors other than google :-)
<tantek> I'm arguing for more modularity not less
<tantek> anyway my objection to the previous resolution is recorded
<TabAtkins> tantek, one property per spec?
<emilio> TabAtkins: yeah we try to be extremely clear when objecting because we understand it's a powerful statement
<RossenF2F> q?
<tantek> TabAtkins: no I'm not interested in strawman like that or fantasai's "GCPM-style hodgepodgs"
<tantek> seriously, not good faith arguments
<RossenF2F> ack florian
<emilio> florian: I heard calls for dropping values and I'd like to push back. We designed this for years in response to use cases. I'm happy to document what the use cases were and maybe rename values so they're better names
<tantek> starting by removing things that lack a reason is the right thing to do
<emilio> ... but until that's done I don't think we should drop values
<tantek> hober++
<RossenF2F> q?
<emilio> hober: that's some work in order to chop things, we'd rather do that now
<tantek> I'm really not sympathetic to features without examples/explanations up front
<emilio> florian: it's just some examples, and I'm sure we won't chop it off
<hober> s/we'd rather do that now/i'd rather spare you the work and chop them now/
<emilio> dbaron: I'd say that's a reason why explainers should have explainers with what they're trying to solve
<emilio> myles_: I don't think that actually conflicts with the env variable proposal
<dbaron> s/explainers should/specs should/
<tantek> if you can't link to the examples / explanations, consider them non-existent
<emilio> florian: I recall people saying there are no use cases but they were, and I'll spend some time cleaning up this and investigate dropping these after we remember what they're for?
<tantek> florian: if you want to postpone dropping, then why not postpone merging also? why is that kind of tentative reasoning good for one postponement and not another?
<tantek> feels pretty inconsistent
<emilio> TabAtkins: I think we agree that stable or something that implements that is good, and that env doesn't solve it
<emilio> ... I think `force stable` seems reasonable too
<emilio> ... as that is what you can use to align
<emilio> ... non-scrollable things to scrollable things
<emilio> cbiesinger: you can use that with the env variable right?
<emilio> TabAtkins: yes
<emilio> florian: don't you need a media query for overlay scrollbars?
<emilio> emilio: env variable would be zero in that case
<emilio> TabAtkins: always is the one you were more skeptical about
<tantek> TabAtkins: "I could see dropping this for now"
<emilio> ... it's done so that you can consistently design stuff across systems
<emilio> ... I could see us dropping always for now
<emilio> ... `both` is intended for always and it seems to be a lot less valuable with stable
<emilio> ... and I think we can drop it for now too
<emilio> ... so we can probably drop them and use `stable` with the `force` keyword, or with the `env()` variable
<emilio> myles_: sounds reasonable
<hober> q+
<RossenF2F> ack TabAtkins
<emilio> fantasai++
<jensimmons> q?
<emilio> florian: my proposal is to revisit this in a week or three
<emilio> ... once we have the cases and alternatives clear
<fantasai> s/cases/cases described/
<tantek> if you're postponing dropping, then postpone merging
<tantek> why is postponing ok for one and not the other?
<TabAtkins> tantek, I'm not happy with you apparently misquoting me to make a point opposite what I'm supporting
<myles_> q-
<RossenF2F> ack hober
<emilio> hober: I wanted to reply to tab
<emilio> ... you said that you're ok dropping always and both, and then between stable + force, or stable + env() you're indifferent right?
<emilio> ... I prefer the env variable
<cbiesinger> q+
<emilio> ... I think it should be an exceptional thing done with particular descendants, and the env variable encourages this a bit more
<RossenF2F> Zakim, close queue
<Zakim> ok, RossenF2F, the speaker queue is closed
<emilio> TabAtkins: are you ok with adding more than two values for different widths?
<emilio> hober: we can get to that once it comes up
<RossenF2F> ack cbiesinger
<emilio> cbiesinger: I agree with hober though for different reasons. I think env() is more understandable for authors than `stable force`
<tantek> I agree with cbiesinger, so don't bother with moving a dead property into a different spec
<emilio> RossenF2F: so next steps florian brings the use cases for the current design
<cbiesinger> well the property isn't dead, just maybe some values of it
<hober> hober: i think we have multi-engine agreement here, which seems worth noting
<tantek> Thanks Rossen for clarifying purpose of scrollbars spec. You're right we should have started there
<tantek> Rossen++ for upleveling the conversation
<emilio> RossenF2F: Re. merging, scrollbar-width/color just styles controls... scrollbar-gutter is more about the box model
<emilio> ... so let's not move everything to scrollbars yet until we know what will remain there
<tantek> That sounds like I need to better document scope in the Scrollbars spec
<emilio> ... next call we'll see whether we stick to that resolution
<tantek> TabAtkins: I've grown very intolerant of time-wasting aesthetics.
<emilio> jensimmons: I like it when this group is able to have discussions and make space for each other instead of going back and forth
<TabAtkins> ScribeNick: TabAtkins

[tantek]

Note that Rossen later followed-up in that same meeting to undo that resolution:

https://www.w3.org/2020/01/23-css-irc#T12-29-54

"RossenF2F: Re. merging, scrollbar-width/color just styles controls... scrollbar-gutter is more about the box model

... so let's not move everything to scrollbars yet until we know what will remain there"

So for now, this no longer impacts CSS Scrollbars.

(Originally published at: https://tantek.com/2020/023/t2/)

[Eli-Black-Work]

I hope this isn't adding noise to the discussion, but I wanted to pop in and say that scrollbar-gutter helped us to make a table with a sticky header where the width of the columns in the table's header are the same width as the columns in the table's body.

Table structure:

|---------------------------------------|
|   header_col1       header_col2       |
|---------------------------------------|
|    body_col1         body_col2        |
|---------------------------------------|
|    body_col1         body_col2        |
|---------------------------------------|
|    body_col1         body_col2        |
|---------------------------------------|

HTML

<div class="table">
   <div class="head">
      <div class="row">
         <div>col1</div>
         <div>col2</div>
      </div>
   </div>
   
   <div class="body">
      <div class="row">
         <div>col1</div>
         <div>col2</div>
      </div>
   </div>
</div>

CSS:

.head, .body {
     display: flex;
     flex-direction: column;
}

.body {
     height: 200px;
     overflow-y: auto;
}

.row {
     display: flex;
}

.row > *:first-child {
     flex: 1;
}

.row > *:last-child {
     width: 100px;
}

Depending on how much content is inside .body, a scrollbar may or may not be shown. If the scrollbar is shown, then the first column ends up being wider in the header than it is in the body.

scrollbar-gutter fixed this:

.body, .head {
     scrollbar-gutter: stable force;
}

What's not clear to me is how the browser knows to give .head a gutter for the vertical scrollbar but not for the horizontal scrollbar.