- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 23 May 2016 13:02:34 -0700
- To: Sebastian Zartner <sebastianzartner@gmail.com>
- Cc: Daniel Buchner <danieljb2@gmail.com>, www-style list <www-style@w3.org>
On Mon, May 23, 2016 at 12:38 PM, Sebastian Zartner <sebastianzartner@gmail.com> wrote: > On 23 May 2016 at 19:48, Tab Atkins Jr. <jackalmage@gmail.com> 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
Received on Monday, 23 May 2016 20:03:20 UTC