Closed tantek closed 5 years ago
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.
@upsuper agreed with your concerns.
We should collect specific use-cases that seem to need scrollbar width control, then design & constrain the feature accordingly.
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.
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.
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
.
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/)
'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/)
border-width
is in both axes, fwiw. And text-decoration-width
follows that pattern.
The Working Group just discussed Scrollbar width
.
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.
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.
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.
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.)
@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
?
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.
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?
Excuse me, I wrote "WD" (Working Draft) - that was a typo. Must be "ED" (Editor's Draft).
@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.
@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?
@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.
Reopen to make spec edits.
@tantek has made the spec edit, we can close this issue again now :)
As a "page author" I'm going to completely customize the GUI. If you make a specification that is pointless I will literally just completely ignore it and implement the features clients request my own way thereby negating the efforts of a "specification". I see zero reason for debate because hot-damn this stuff is ridiculously easy.
I highly recommend listening to the market which in this case are people who build and design using the specifications or in the absence of competent specifications hacky-work-arounds. While I am not the market as a whole I am the lead developer of a web platform and have to handle ensuring reasonably defaults without denying clients the ability to customize to their heart's content.
@jabcreations please moderate your language if you want to contribute here. You can express your opinion without editorializing about the competence of others.
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.
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?
No, I don't think there's any discussion about removing it.
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 Webkit system-rendered scrollbars may not be designed to be rendered at variable widths, but they are check
select[multiple]
andselect[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.
Should we also add scrollbar width control? @tabatkins noted in the f2f that Google uses scrollbar width modification in Gmail and Google Docs.