Re: Var for scrollbar size

On Thu, May 19, 2016 at 11:56 PM, Sebastian Zartner
<sebastianzartner@gmail.com> wrote:
> On 20 May 2016 at 01:02, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>
>> On Wed, Apr 27, 2016 at 9:16 AM, Daniel Buchner <danieljb2@gmail.com> 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
everywhere.

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

~TJ

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