Var for scrollbar size

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Var for scrollbar size

Daniel Buchner-2
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,

- Daniel
Reply | Threaded
Open this post in threaded view
|

Re: Var for scrollbar size

Tab Atkins Jr.
On Wed, Apr 27, 2016 at 9:16 AM, Daniel Buchner <[hidden email]> 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. ^_^

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?

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: Var for scrollbar size

Sebastian Zartner-3
On 20 May 2016 at 01:02, Tab Atkins Jr. <[hidden email]> wrote:

>
> On Wed, Apr 27, 2016 at 9:16 AM, Daniel Buchner <[hidden email]> 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.

Sebastian

Reply | Threaded
Open this post in threaded view
|

Re: Var for scrollbar size

Tab Atkins Jr.
On Thu, May 19, 2016 at 11:56 PM, Sebastian Zartner
<[hidden email]> wrote:

> On 20 May 2016 at 01:02, Tab Atkins Jr. <[hidden email]> wrote:
>>
>> On Wed, Apr 27, 2016 at 9:16 AM, Daniel Buchner <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Var for scrollbar size

Sebastian Zartner-3
On 23 May 2016 at 19:48, Tab Atkins Jr. <[hidden email]> wrote:

>
> On Thu, May 19, 2016 at 11:56 PM, Sebastian Zartner
> <[hidden email]> wrote:
> > On 20 May 2016 at 01:02, Tab Atkins Jr. <[hidden email]> wrote:
> >>
> >> On Wed, Apr 27, 2016 at 9:16 AM, Daniel Buchner <[hidden email]> 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.

Ok, animation could be a use case. Though is there actually a use case
for using the scrollbar size in animations?

> Or wanting to pad the area out a little bigger
> than the scrollbar width, so 1.2scrollbar or something.

As the scrollbar size is something out of control of the author, they
probably would rather use a calc() expression in that case like e.g.
calc(scrollbar + 5px).

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

Yes, slightly less convenient, though regarding the assumed default
usage above with a mix of 'scrollbar' and a <length> or <percentage>
value you'd have to use calc() anyway.

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

If I'm not mistaken, there is no property at the moment taking
<custom-ident> or <length> at the same time. And if there is a syntax
allowing this, it would need to be checked if 'scrollbar' is used
anywhere as <custom-ident> in that case.
If there's no such case, it could simply be disallowed in that combination.

Different approach:
Explicitly add 'scrollbar' as keyword to property syntaxes where
needed. Reason is that for many properties its usage doesn't make much
sense, like the border-*-radius properties, for example.

Sebastian

Reply | Threaded
Open this post in threaded view
|

Re: Var for scrollbar size

Tab Atkins Jr.
On Mon, May 23, 2016 at 12:38 PM, Sebastian Zartner
<[hidden email]> wrote:
> On 23 May 2016 at 19:48, Tab Atkins Jr. <[hidden email]> wrote:
>> Sure there is. For example, animating from 1scrollbar to 0 needs the
>> intermediate values.
>
> Ok, animation could be a use case. Though is there actually a use case
> for using the scrollbar size in animations?

Of course; animating padding to/from 0 is a generic use-case.

>> Or wanting to pad the area out a little bigger
>> than the scrollbar width, so 1.2scrollbar or something.
>
> As the scrollbar size is something out of control of the author, they
> probably would rather use a calc() expression in that case like e.g.
> calc(scrollbar + 5px).

Maybe, or maybe not.  People often use something that looks reasonable
rather than something absolutely perfect/well-reasoned, and bumping up
to a higher multiple of the scrollbar size can easily achieve
reasonable results for "a little more padding there, the text is a
little too close to the scrollbar". Same as people simply using a
slightly higher 'em' value rather than explicitly busting out a calc()
to add a set number of pixels to an existing length.  This is okay
behavior!

>> 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.
>
> If I'm not mistaken, there is no property at the moment taking
> <custom-ident> or <length> at the same time. And if there is a syntax
> allowing this, it would need to be checked if 'scrollbar' is used
> anywhere as <custom-ident> in that case.
> If there's no such case, it could simply be disallowed in that combination.

Yeah, I'm not sure if there's any in existence *yet*, but there could
be; it's a perfectly reasonable combo.

The issue is that having to worry about an arbitrary set of disallowed
keywords is hard/annoying/error-prone, both for page authors *and*
spec authors!  We currently only have to blanket-disallow the global
keywords, which is pretty easy to remember and deal with; any other
restrictions are case-specific and defined close to the definition of
that <custom-ident>. Adding a keyword that we have to disallow
whenever it might be ambiguous with a <length> is *much* more
confusing and likely to be missed.  That's not good design.

> Different approach:
> Explicitly add 'scrollbar' as keyword to property syntaxes where
> needed. Reason is that for many properties its usage doesn't make much
> sense, like the border-*-radius properties, for example.

Assuming one knows exactly how people are going to use a new value
like this, and baking those assumptions deeply into the design, is
often a recipe for failure.  While I can't come up with a usage off
the top of my head, I'm certain they exist, and disallowing it just
leaves people without a way to reproduce this functionality.  We have
a simple, easily-extensible way to do new lengths, that works
everywhere and handles all sorts of unanticipated usages. We should
use that.

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: Var for scrollbar size

fantasai
On 05/23/2016 04:02 PM, Tab Atkins Jr. wrote:

> On Mon, May 23, 2016 at 12:38 PM, Sebastian Zartner
> <[hidden email]> wrote:
>> On 23 May 2016 at 19:48, Tab Atkins Jr. <[hidden email]> wrote:
>>> Sure there is. For example, animating from 1scrollbar to 0 needs the
>>> intermediate values.
>>
>> Ok, animation could be a use case. Though is there actually a use case
>> for using the scrollbar size in animations?
>
> Of course; animating padding to/from 0 is a generic use-case.

... this seems rather contrived here.

>>> Or wanting to pad the area out a little bigger
>>> than the scrollbar width, so 1.2scrollbar or something.
>>
>> As the scrollbar size is something out of control of the author, they
>> probably would rather use a calc() expression in that case like e.g.
>> calc(scrollbar + 5px).
>
> Maybe, or maybe not.  People often use something that looks reasonable
> rather than something absolutely perfect/well-reasoned, and bumping up
> to a higher multiple of the scrollbar size can easily achieve
> reasonable results for "a little more padding there, the text is a
> little too close to the scrollbar". Same as people simply using a
> slightly higher 'em' value rather than explicitly busting out a calc()
> to add a set number of pixels to an existing length.  This is okay
> behavior!

Authors want to control spacing pretty exactly in most cases.
I can see wanting "match the scrollbar size" but not "match the scrollbar
size plus 2%". You can add on 2px or whatever seems appropriate -- I can't
think of a reason why you'd want it as a percentage of the scrollbar size.

~fantasai
who would like to see a layout that needs this, that can't otherwise be
solved with an invisible variant of 'overflow: scroll'