[css-scrollbars][css-scrollbars-1] Should we also add scrollbar width control?

[tantek]

Should we also add scrollbar width control?
@tabatkins noted in the f2f that Google uses scrollbar width modification in Gmail and Google Docs.

[upsuper]

As I've noted in the f2f, I'm concerned about having exact width control can yield to undesired rendering in different platforms. Windows and macOS and Ubuntu all seem to all have different width for scrollbar.

I guess if we want width modification, we should do either max width or some ratio to the default size.

[tantek]

@upsuper agreed with your concerns.

We should collect specific use-cases that seem to need scrollbar width control, then design & constrain the feature accordingly.

[iamdustan]

We also rely on scrollbar width modification at Webflow for our Designer. IIRC there may be a nuance with scrollbar width and container width or getBoundingClientRect() results or some other JS interop, but I’d need to spend time spelunking to have anything concrete to say there.

[silverwind]

Note that a "width" terminology wouldn't work for horizontal scrollbars. Maybe "thickness" is a better fitting term, thought I'm not too happy with that name either.

[frivoal]

Not sure. width can be (and usually is in CSS) paired with height, so I see your point, but it can also be paired with length. Given that scrollbars are long-and-thin things, I doubt anybody would be confused about what we're talking about when using the word width about a horizontal scroll bar.

As a non native english speaker, I'd rather keep width than thickness.

[tantek]

There appears to be consensus at least in the current comments on this issue for adding a property to modify scrollbar size, with some additional preference for that to be treated as a maximum size, allowing implementations to show smaller scrollbars if it’s more appropriate.

I have captured the use-cases mentioned here and to me in person on the wiki accordingly:

<https://www.w3.org/wiki/Css-scrollbars#Web_App_small_scrolling_areas>

Regarding the concern about terminology raised by <https://github.com/silverwind> about using "width" for horizontal scrollbars, vs the suggested alternative "thickness", note that CSS already has a notion of modifying the width of horizontal and vertical "bars" in the 'border-width' and 'outline-width' properties.

In particular note the pre-existing 'border-top-width' and 'border-bottom-width' properties (<https://drafts.csswg.org/css-backgrounds-3/#border-width>) which specifically apply to horizontal borders. Thus I think it is both ok and desirable to use "width" to refer to the scrollbar size as well, since it is consistent with those existing properties, and matches what web developers will likely already be familiar with in CSS.

I’m going to specify a 'scrollbar-width' property that takes length units that sets the maximum width of any scrollbars on an element when they are shown. 'auto' will be used as the initial value that means just use the platform default scrollbar size.

(Originally published at: http://tantek.com/2018/185/t1/)

[tantek]

'scrollbar-width' added to the draft accordingly with a few details defined, and a few details in notes. Please review:

<https://drafts.csswg.org/css-scrollbars-1/#scrollbar-width>

Comment if you find aspects we can improve.

Thumbs-up this comment if everything looks good enough for a public working draft.

(Originally published at: http://tantek.com/2018/185/t5/)

[fantasai]

border-width is in both axes, fwiw. And text-decoration-width follows that pattern.

[css-meeting-bot]

The Working Group just discussed Scrollbar width.

The full IRC log of that discussion

<TabAtkins> Topic: Scrollbar width
<astearns> github: https://github.com//issues/1958
<fantasai> plinss, text-decoration-skip: objects
<TabAtkins> tantek: We had a rough consensus among people who cared to add a scrollbar-width property.
<TabAtkins> tantek: We think it's implementable.
<TabAtkins> tantek: Wanted to bring it to people's attention in case there are opinions.
<TabAtkins> tantek: This is one of the key things I wanted to resolve one way or the other before fpwd. Other was color properties.
<TabAtkins> heycam: This sets the maximum width? Why?
<TabAtkins> astearns: That was some feedback from Xidorn where the UA might want to display something smaller sometimes...?
<TabAtkins> tantek: Right. You might want to limit how wide a scrollbar can be, but not force platforms that do narrower ones to draw wide.
<TabAtkins> frremy: scrollbar-max-width?
<TabAtkins> myles: Worried for two reasons.
<TabAtkins> myles: First is macos scrollbars have two widths, they switch between.
<TabAtkins> myles: Such a model can't express that.
<TabAtkins> myles: Second is that on windows, scrollbar widths will change if you're using touch or not.
<TabAtkins> myles: So that also doesn't fit with this property
<TabAtkins> myles: Also, OS should be the one that sets these complicated models, not websites.
<fantasai> TabAtkins: A lot of websites have very narrow scrollbars, and that is exactly the reason why they are using non-native scrollbars
<TabAtkins> tantek: You brought up a good reason for the max treatment.
<TabAtkins> tantek: Platforms can switch between widths *within* the property's value.
<TabAtkins> tantek: so like on macos it starts small and gets bigger on hover - you can still do that with max-width.
<TabAtkins> frremy: When it gets bigger it's overlay, right?
<TabAtkins> myles: When you're using non-overlay scrollbars, it doesn't change size on hover.
<TabAtkins> frremy: So the width should just be the layout size
<TabAtkins> tantek: Maybe the size is jsut the initial size, the expanding can ignore that?
<TabAtkins> myles: Problem is just that there's already three modes on macos, i worry about letting pages control this.
<TabAtkins> astearns: Not allowing this property doesn't save users from terrible scrollbars. Pages will use custom (terrible) scrollbars.
<TabAtkins> astearns: This jsut lets them specify a max width, you can still do nice native scrollbars.
<TabAtkins> xidorn: I guess myles' point is whether the width should apply to overlay scrollbars, which I'm not sure.
<TabAtkins> xidorn: I discussed with tantek before, and thought it should be applied to overlay as well.
<TabAtkins> xidorn: But then we have problems - it may restrict the ability to expand the scrollbar.
<heycam> q+
<TabAtkins> myles: One other piece I want to mention is that setting this property shouldn't force scrollbars to be take up layout space.
<TabAtkins> tantek: It doesn't.
<TabAtkins> xidorn: It might make the layout space *smaller*.
<TabAtkins> xidorn: Whether this should apply to the appearance of overlay scrollbars is another issue.
<astearns> ack heycam
<TabAtkins> heycam: What is the use-case for allowing a specific width to be specified, and whether it's sufficient to just request "thin"?
<TabAtkins> myles: So if our users select that they want scrollbars to take up layout space, we don't have a thinner version.
<TabAtkins> q+
<frremy> q+
<TabAtkins> tantek: I think the problem to solve is that users are creating a totally new scrollbar just to make it thinner. The work there is suboptimal due to usability.
<TabAtkins> tantek: Hope is that we can reflect the underlying platform's behavior better.
<fantasai> tantek: ...
<TabAtkins> myles: I'm sympathetic to the idea that giving authors a way to get the behavior they want without building it themselves is better.
<TabAtkins> myles: I'm not very convinced that this will be the impetus to stop building things themselves.
<tantek> q+ to note perhaps we can *add* 'thin' as a keyword so authors can ask for a thin scrollbar without having to worry about specific pixels per platform?
<TabAtkins> Rossen: From xidorn's comment; if i set the max-width, at least we're going to affect the layout size
<TabAtkins> Rossen: If that exceeds the width of the scrollbar, that'll be weird.
<TabAtkins> TabAtkins: That's why it's a max width.
<TabAtkins> Rossen: So it doesn't go above the visual width of the scrollbar. With hidey-scrollbars, the width stays at zero.
<astearns> ack TabAtkins
<TabAtkins> [something from me]
<TabAtkins> tantek: Side issue - there are a lot of people discussing on the issues *demanding* the webkit model. If there was a canonical link I could point people to, it would be useful.
<xidorn> q+
<astearns> ack frremy
<TabAtkins> frremy: I think the more recent proposal was for having a "thin" keyword sounds good. And if they want "thin", maybe use overlay for that specific element?
<TabAtkins> frremy: REquest we get often is that people want dark scrollbars, and people want tinier scrollbars.
<fantasai> s/scrollbars/scrollbars, for things like chat windows/
<TabAtkins> frremy: So yeah, maybe rather than a specific size, we just have a "thin" keyword that opts into the OS's smaller version.
<TabAtkins> myles: So let's pretend I'm on gtk linux that only has one size...
<TabAtkins> frremy: Then it's just the one size, that's an OS size
<TabAtkins> s/size/limitation/
<TabAtkins> myles: So this can't be tested?
<fantasai> TabAtkins: We try to minimize manual tests, but it's not a case of if it's notpossible to machine test it doesn't exist.
<astearns> q?
<TabAtkins> myles: So what happens if you test on an OS that only has one scrollbar size?
<TabAtkins> tantek: It passes.
<TabAtkins> myles: So author has to know what all the platforms do...?
<TabAtkins> TabAtkins: Don't worry about GTK, everyone uses macos, windows, or chromeos. ^_^
<TabAtkins> dbaron: And GTK *does* have two widths anyway.
<astearns> ack tantek
<Zakim> tantek, you wanted to note perhaps we can *add* 'thin' as a keyword so authors can ask for a thin scrollbar without having to worry about specific pixels per platform?
<TabAtkins> tantek: So if we just add a thin value we can see what feedback we get.
<TabAtkins> TabAtkins: I'd accept that in my use-case, yeah.
<Rossen> q+
<fantasai> ...
<fantasai> tantek: A lot of what we do is replace JS hacks.
<astearns> ack xidorn
<TabAtkins> xidorn: I'd like to raise that there was actually another use-case I'd like to solve with scrollbar-width
<TabAtkins> xidorn: Some authors just want to make their own scrollbars, and want to make the native be hidden, but still be scrollable.
<TabAtkins> xidorn: I think that's a reasonable use-case as well. Even if their custom is terrible, it's still better than "overflow:hidden".
<fantasai> TabAtkins: Rich Byers had some proposal for having a scroller but without a visible scrollbar
<fantasai> ScribeNick: fantasai
<astearns> ack Rossen
<fantasai> Rossen: Couple points, the first one is for the lenght value
<fantasai> Rossen: If we were going ot go with a length value as it's currently specified
<fantasai> Rossen: There has to be some affordances, or at leats explain how scaling works
<fantasai> Rossen: E.g. in Edge we go to a great extent to make sure that the frame scrollbars never scale as you pinch-zoom, so that your scrollbar doesn't take over the entire surface of your device
<fantasai> Rossen: At the same time, content will scale
<fantasai> Rossen: So already a discrepency at least in our case
<fantasai> Rossen: between scrollbars attached to the frame and the content in the frame
<fantasai> tantek: gestures or other zoom?
<fantasai> Rossen: For browser zooms, we always keep the same scrollbar size as every other scrollbar in the system
<fantasai> Rossen: Not expecting any action, but it has to be considered
<tantek> s/other zoom/other zoom like zoom property
<fantasai> Rossen: The other thing is that scroll spec started off that you have a lot of interop bugs that were being reported to you and since the last time we talked about this
<fantasai> Rossen: couple things I realized
<fantasai> Rossen: Firstly, we removed all styling of scrollbars in Edge 4 yrs ago
<fantasai> Rossen: and we have absolutely no bugs reported to us about styling scrollbars
<fantasai> Rossen: so curious where we're going with this
<fantasai> frremy: Actually, we keep getting bugs from Outlook complaining to us about this.
<fantasai> ...
<fantasai> Rossen: To myles's point, ppl want more control
<fantasai> Rossen: Are we tryng to go more towards this model, or try to lock it down?
<fantasai> Rossen: thin/medium/thick scrollbars and some colors and leave it there
<fantasai> tantek: The hope is that a small number of properties is enough to satsify users
<fantasai> tantek: There are sites that will outright block browsers based on support for scrollbar styling
<fantasai> myles: New thing won't solve existing problem?
<fantasai> tantek: They're putting effort into trying every possible way to style the scrollbars, so expect they'll update with new thing if it's available
<fantasai> myles: Sites are saying that color of the scrollbar is so important they'd rather people not use their service?
<fantasai> tantek: Yes.
<tantek> https://www.w3.org/wiki/Css-scrollbars#Sites_blocking_browsers
<fantasai> xidorn: It's not so much about specific colors, but e.g. they have a dark interface and they don't want light scrollbars
<tantek> https://webcompat.com/uploads/2017/7/96051d95-3863-4285-8b02-245403aeb160-thumb.jpg
<fantasai> Rossen: I think the keyword values would be better
<fantasai> Rossen: Either adding or replacing <length>
<fantasai> myles: Scrollbars are a evolving technology
<fantasai> myles: A few years ago MacOS scrollbars had up/down arrows
<fantasai> myles: Then we went to overlay and dropped the arrows
<fantasai> myles: Then went to two different overlay
<fantasai> myles: Windows has similar evolution
<fantasai> myles: You need to consider how this works with all of the complexity today, and also how it could work in the future
<fantasai> tantek: I agree with that, and been resistent to speccing this in general
<fantasai> tantek: So trying to figure out with specific use cases
<fantasai> tantek: As much as scrollbars have evolved, some way to control color has been constantly desired. Same with width
<fantasai> tantek: I would agree with your statement of being mindful of the future.
<fantasai> tantek: Question is, do folks want a thin keyword?
<fantasai> astearns: Choice is between having width that allows for zero, or having at least two keywords
<fantasai> astearns: thin/none/auto
<fantasai> Rossen: Can we take the length value out of the picture?
<fantasai> astearns: So do we have <length> or thin | auto | none ?
<TabAtkins> fantasai: If you wanna get rid of the scrollbar you can put it to 0 or none, same effect.
<TabAtkins> fantasai: But what do you mean by "thin"? If the author is caring about the width fo the scrollbar, they want it to be narrower than a particular amount.
<TabAtkins> astearns: Tab's use-case was fine with "thin".
<TabAtkins> fantasai: So what if scrollbars are 10px by default, but a thin version is 5px. They say "thin". But then later scrollbars default to 5, and thin is 2px, it's smaller than they intended!
<fantasai> TabAtkins: If it's 10px and 5px for thin, and author says 6px it's fine, it'll choose 5px one
<fantasai> TabAtkins: Late rOS change such that it's 8px and 3px, it'll go down to only 3px
<tantek> q?
<tantek> q+ dbaron
<TabAtkins> frremy: I don't think scrollbars will keep getting smaller, they're about as small as they'll get.
<TabAtkins> Rossen: Disagree, we keep changing them as well.
<TabAtkins> Rossen: Going back to Simon's statement that scrollbars as OS-level, and we shouldn't mess with them. I don't disagree with this.
<TabAtkins> Rossen: If the platform offers multiple sizes, maybe we give control over choosing that, ok. Maybe we want to give a little bit of color control, okay. But taking over system controls, you either take it over or you don't.
<TabAtkins> Rossen: For any other system control, like a button, they take it over totally. They use an image and script.
<tantek> q?
<astearns> ack dbaron
<TabAtkins> myles: So you're saying that authors should have no control, and should use JS entirely.
<TabAtkins> dbaron: An idea floated around was specifying a size and getting nearest-available size.
<TabAtkins> dbaron: Problem with that is people try out sizes and fiddle around until it looks good.
<florian> q+
<TabAtkins> dbaron: They can end up getting a different size than they ask for, but it looks okay, and then later changes violate what they want while still technically respecting what they say.
<TabAtkins> frremy: REason I disagree - if you ask for "thin" on mac you'll get overlay, 0 layout size.
<dbaron> dbaron: naming the property well can mitigate that risk
<TabAtkins> frremy: It seems way easier to just say "normal" or "thin", and they're up to the UA.
<TabAtkins> myles: On macos, there's layout and overlay scrollbars.
<TabAtkins> myles: If the author's threshold is larger than layout scrollbars they get that, if thinner they get overlay. Right?
<TabAtkins> myles: So the functionality seems to end up being flipping overlay on and off, which isn't what it's meant for!
<TabAtkins> tantek: I don't think flipping that switch is what was intended.
<tantek> s/switch/layout switch
<TabAtkins> myles: But macos has just two scrollbars - 16px and 0px. If your max-size is 15px, it'll turn on overlay.
<TabAtkins> myles: This is what I was getting at - we need to think deeply about how this affects scrollbar models today and in the future.
<TabAtkins> frremy: Problem is that the longer we wait, the more custom scrollbars we get.
<fantasai> myles: They want everything
<fantasai> TabAtkins: What they want and what they'll accept are two differnet hings
<astearns> ack florian
<TabAtkins> TabAtkins: And we're hoping we can hit their accept threshold with fairly little stuff.
<TabAtkins> florian: Re elika's point about getting something ridiculously tiny - maybe in the keywords we can have more than just auto|thin, we can add |hairline. That's definitely distinct in intent, while still allowing threshold.
<TabAtkins> myles: What if the OS's thinnest scrollbar is wider than the length?
<TabAtkins> TabAtkins: This is why frremy suggests just doing keywords, elkminate that problem.
<TabAtkins> florian: Note that scrollbar-gutter can solve some of those problems too.
<tantek> https://drafts.csswg.org/css-overflow-4/#scollbar-gutter-property
<TabAtkins> fantasai: And scrollbar-gutter should be in the same spec as this.
<TabAtkins> myles: So tantek you don't need resolutions yet, right?
<TabAtkins> tantek: My normal appraoch is to put in all the possibilities so we can discuss it with wider population.
<fantasai> s/this/this, if we go to FPWD/
<TabAtkins> tantek: So my inclination is to add "thin" and keep length for now.
<TabAtkins> Rossen: I think if we have the keyword and everyone revolts, we can think about adding lengths back.
<TabAtkins> TabAtkins: I agree, and I think lengths have a harder time of getting thru the committee anyway.
<TabAtkins> myles: My preferred solution is still option 3 - none of this proposal at all.
<TabAtkins> Rossen: +1
<TabAtkins> TabAtkins: I strongly disagree, as do our a11y people, but I understand your position, because it's what Simon has said every time this has come up.
<florian> q+
<TabAtkins> tantek: So I guess question is - would anyone object to going to fpwd with the width property at all, and would width with <length> draw objection?
<TabAtkins> Rossen: I wont' object to keywords. I'd object ot length
<TabAtkins> myles: We don't object to it in either form.
<astearns> ack florian
<TabAtkins> florian: I don't object to any particular, but to me fpwd signals we have details to figure out, but general agreement on the approach.
<TabAtkins> florian: I'm not sure we have agreement on appraoch yet. Not objecting, just noting.
<TabAtkins> myles: In addition to what I just said, which sounded positive, we're actually reluctant.
<TabAtkins> [talking about fpwd vs patents]
<TabAtkins> tantek: I'm hearing the least objection to putting *something* about length in there.
<TabAtkins> myles: Two browsers are reluctant.
<TabAtkins> tantek: If you really objected you'd drop the ::-webkit stuff.
<TabAtkins> myles: We don't comment on future software releases.
<TabAtkins> xidorn: Our position is that pushing this would help wk/blink drop the pseudo-elements.
<TabAtkins> xidorn: This is one of the use-cases we've heard.
<TabAtkins> tantek: Right. We think some of the users currently using ::-webkit stuff will be amenable to switching, and the -width property will contribute to that.
<TabAtkins> tantek: So my goal is to put it in for now. We can always decide in a subsequent draft to drop it.
<TabAtkins> florian: I'd be happier for fpwd if we agreed on earlier discussion.
<TabAtkins> fantasai: I think we're clear that this is about the simplest possible thing we could do.
<fantasai> s/do/do to control the width/
<TabAtkins> astearns: Rossen objected to "-width:<length>". If there was a scary warning, would that get thru your objection?
<TabAtkins> Rossen: Yeah.
<TabAtkins> proposed resolution to add "thin", and a big warning note about <length>, then go to fpwd.
<TabAtkins> [discussion about whether keywords, length, or both]
<TabAtkins> astearns: And you should include a note about disagreement aobut the existence of the property itself
<TabAtkins> astearns: Would you object to fpwd with the colors as stated?
<TabAtkins> fantasai: I think I would.
<TabAtkins> fantasai: If a key use case is light/dark, we should have those as choices <TabAtkins> astearns: Then we're out of time and will have to come back to this.

[upsuper]

As a prior art, Microsoft has -ms-overflow-style property to provide part of the functionality, specifically hiding scrollbar while keep scrollable. That property also allows making scrollbar overlay on Windows, which I'm not sure whether would fit usecases of thin scrollbar.