[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.

[smfr]

I'm not convinced that WebKit would ever add support for a scrollbar width property. Our system-rendered scrollbars are not designed to be rendered at variable widths, and we don't think that allowing web pages to deviate from the system norms is useful.

[tabatkins]

As expressed in the F2F minutes, there's quite a bit of sites that currently alter their scrollbar width, in particular to make them skinnier than the platform default. This includes most Google properties, for example. This is why one of the major themes of the discussion was at least making this keywords, with thin as an option.

Full control over width may not be amenable here, but at least a smidge of control seems called for, given the current population of custom scrollbars.

[upsuper]

With scrollbar-width added to the spec, I think we can close this now? We would at least have auto | thin | none to give some control to authors.

This property as well as the three keyword values have been implemented in Firefox Nightly on all desktop platforms behind pref "layout.css.scrollbar-width.enabled". (It is also supported on Android but still has some bug to be tackled.)

[jonjohnjohnson]

@smfr

I'm not convinced that WebKit would ever add support for a scrollbar width property

It seems you are mostly talking about variable widths, but not the none value of scrollbar-width which would more simply address all the cases I see in iOS where authors are using negative margins to hide nuisance scrollbars? I see this all the time for horizontal scrollers, even most google search results has their horizontal scrolling <g-scrolling-carousel> that shows how prevalent techniques like ::-webkit-scrollbar {display: none} or negative margins & hidden overflow are used to hide scrollbars while still taking advantage of native browser scrolling.

Is webkit completely against even the responsible use of scrollbar-width: none?

[franckyK]

Apart form the technical stuff (I don't know if there might be complications for "writing-mode:vertical"), here some more pricipal notes from a user POV.

• What I like of visible (vertical) scrollbars is that you can see (by the height of the scrollbar) how many screenheights a page or element will be. When developers get the freedom of "scrollbar-width: none" ("not display any scrollbar, however the element’s scrollability is not affected", the WD says), as a user I'm losing control about my browser behaviour.
• If an element has a white space just in between two sub-elements, it is not obvious that there will be more if scrolled - and visitors can miss important information (f.i. an "order now" button under the water line, or things with juridical consequences). Adding several internal "Read more" links to overcome this will not create the most elegant websites.
• I can imagine that for touch-screens maybe a disappeared scrollbar is an option, but anyway it is not very user friendly if there is no mandatory rule as "if the scrollbar-width is set to none, a user agent MUST give an indication that the element is scrollable" (f.i. with an icon or something).
• Then the scrollbar-width. As a desktop-fan I'm used to mouse to handle a scrollbar, and when a scrollbar is "thin" the user-friendlyness or even accessibility is in danger. There should be at least a prescribed minimum for the scrollbar-width, I think.
• Not unimportant: there is a firm uncertainty about the scrollbar behaviour by (different!) user agents: "This specification does not define the exact position or shape of the scrollbar, or any animation thereof, such as fading or sliding in/out of view." Growing and lawless diversity instead of standards is a threat for the common and disabled user...

Considering all this (and with the still often misused "outline:none" in mind), it shouldn't amaze me if shortly after reality of this WD there would emerge browser add-ons as "ShowMyScrollbarAlways", in case good browsers don't include that as a setting in the browser options itself. But better should be the opposite: always show scrollbars, unless "hide" is permitted by the user (opt-in instead of opt-out). Then the user remains the king!

At last a question: is the WD going round in the WAI circles, and what do they think?

[franckyK]

Excuse me, I wrote "WD" (Working Draft) - that was a typo. Must be "ED" (Editor's Draft).

[jonjohnjohnson]

@franckyK I don't think anyone is arguing for the use of scrollbar-width to be used in environments where someone can or should be using the scrollbar. Think Android or iOS, there are scrollbar visuals, which aren't usable by means of "grabbing". We have browser features like scroll-snap that allow for things like optimized image carousels, or emulating what native iOS has as a "swipe view". When authors develop/design these interfaces, they should be using the scrollbar-width property responsibly to uphold a good experience for the user.

This isn't a feature that has been requested for the motivation to remove scrollbars on a normal body scrolling website and make it harder for accessibility. This is a feature that is needed in place of many hacky css/js layout treatments that hide nuisance scrollbars, when the scrollbar, mostly as an ornament, is confusing a user. People hide scrollbars for good reasons. This feature is allowing that to be done cleanly, if the author decides it's good for the interface/user.

Imagine the photos app on your phone, that surely animates/snaps as you swipe between individual photos, while maybe showing a sliver of the previous and next photos. Without scrollbar-width: none there would be a useless ornamental scrollbar covering the bottom of the screen without an actionable relationship to how many photos are in the sequence or which photo you are actually at (a scrollbar is not a paginator) when creating this interface in a browser.

[jonjohnjohnson]

@smfr To follow up on my previous question about your perspective on scrollbar-width rendering at variable widths on apple systems.

On macOS I see the finders quick look functionality showing a "thin" scrollbar.

In iOS Safari I see facebook attempting to hide a scrollbar with overflow:hidden and a negative margin-bottom value around a horizontal scroll container. You can see a sliver of the scrollbar accidentally showing.

Is this really a property webkit won't want to implement from the current spec?

[franckyK]

@jonjohnjohnson: Thank you for the quick response. Maybe I wasn't clear enough in my post above (English is not my native language).
Yes, I agree 100% with the motivation as a standarized mechanism to get rid of useless/disturbing scrollbars, especially for touch devices. I don't worry about these improvements. Neither I'm afraid for the implementation by platforms and user agents.
My point of concern is the possible improper use regarding to desktops, in the wild enabled for everybody by a simple "scrollbar-width: none" rule. If unconditional use is prohibited as much as possible, my concerns will melt as snow on a hot summer day.
To finish my contribution to this topic, an impovised demo of my imagination (and some thinking aloud about resolution directions) is over here: http://clba.nl/experiments/scrollbar-none.htm.

[smfr]

Reopen to make spec edits.

[upsuper]

@tantek has made the spec edit, we can close this issue again now :)

[astearns]

@jabcreations please moderate your language if you want to contribute here. You can express your opinion without editorializing about the competence of others.

[pat270]

I'm not convinced that WebKit would ever add support for a scrollbar width property. Our system-rendered scrollbars are not designed to be rendered at variable widths, and we don't think that allowing web pages to deviate from the system norms is useful.

@smfr Webkit system-rendered scrollbars may not be designed to be rendered at variable widths, but they are check select[multiple] and select[size]. They use thin scrollbars.

[Fuseteam]

so i ended up here from caniuse page claiming this probably might get removed. however i don't get that intention from the above discussion. will it really be removed? will there be an alternative?

[upsuper]

No, I don't think there's any discussion about removing it.

[Fuseteam]

then i guess that page needs to be updated, looking at the recent spec edit. i can sort of see what that idea may have come from

[smfr]

@smfr Webkit system-rendered scrollbars may not be designed to be rendered at variable widths, but they are check select[multiple] and select[size]. They use thin scrollbars.

There is a fixed set of control sizes, including "normal" and "small" variants. WebKit chooses to use the "small" variant on some controls, but this may vary between platforms.