Re: Var for scrollbar size

On Mon, May 23, 2016 at 12:38 PM, Sebastian Zartner
<[email protected]> wrote:
> On 23 May 2016 at 19:48, Tab Atkins Jr. <[email protected]> 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