Re: Var for scrollbar size

On Thu, May 19, 2016 at 11:56 PM, Sebastian Zartner
<> wrote:
> On 20 May 2016 at 01:02, Tab Atkins Jr. <> wrote:
>> On Wed, Apr 27, 2016 at 9:16 AM, Daniel Buchner <> wrote:
>> > Hey Dub Stylers!
>> >
>> > Not sure why I never thought of this all the times I have needed it, but
>> > after running into it again today I started wondering why there isn't a var
>> > in CSS that represents scrollbar size?
>> >
>> > I would love to have a var like currentColor that stands for the scrollbar
>> > size; it would really help in layouts where you want to prevent snap from
>> > scrollbar appearance, accounting for fixed element overlap of non-viewport
>> > scrollable elements, etc.
>> >
>> > So how 'bout it, anyone up for scrollbarSize? :)
>> >
>> > Let me know what you think,
>> Yup, we've discussed this internally, and it came up at the last f2f.
>> I recommend adding it as a new unit, like "1scrollbar"; that lets the
>> value work in calc() without depending on us finally fixing the "allow
>> keywords in calc()" issue. ^_^
> Having this as unit sounds like a rather hacky solution. There is
> probably no need for 3scrollbar or 0.5scrollbar.
> So, I vote for pushing on fixing the "allow keywords in calc()" issue
> instead or find another solution to consider the scrollbar sizes in
> dimensions.

Sure there is. For example, animating from 1scrollbar to 0 needs the
intermediate values.  Or wanting to pad the area out a little bigger
than the scrollbar width, so 1.2scrollbar or something.

Both of these can be achieved with keyword-calc, of course - calc(1.2
* scrollbar) - but it's slightly less convenient.

Also, this would be the first universal <length> keyword; all others
are specific to the property. This has the possibility of introducing
ambiguity that's not currently there, if there are any places in CSS
that expect a <custom-ident> *or* a <length>.  These issues are
avoided with a new unit, because <dimension>s are unambiguous

> We'd have to define what happens when you're doing custom scrollbars
> and have them set to different sizes.  We *could* do two units, one
> for each, but that seems overcomplicated for a super-minority case
> (that seems like it'd be ugly, anyway). Maybe just make it be the
> larger of the two?

Rethinking this, I'd actually prefer the scrollbar unit to *not*
respond to custom scrollbars. Doing so makes it a computed-value-time
unit *at minimum* (I dunno if custom scrollbars can use percentages?),
and, as I said, brings up the ambiguity over which of the two
scrollbars you're using.  All *system* scrollbars in existence are the
same size in both axises, and their size is known at specified-value
time, which would make the unit a lot easier to use and more useful.
If you're using custom scrollbars and want to respond to them, you
should just use CSS variables.


Received on Monday, 23 May 2016 17:49:00 UTC