Re: [css-variables] Why so inefficient?

On 02/16/2016 06:35 PM, Tab Atkins Jr. wrote:
>
> We need a var() function for a few reasons.  For one, there are a few
> places in CSS where you can have arbitrary names already, like counter
> styles or animation names, so allowing a bare custom property name
> would be ambiguous there.  Theoretically we could make it invalid to
> name your @keyframes or @counter-style rule something that looks like
> a custom property name, but that means more rules for authors to
> learn.

I think --foo is sufficiently weird that we don't need to worry about
this here.

> For two, var() is required in some circumstances, like when you want
> to provide a fallback.  In general, a language shouldn't provide
> multiple ways to do something unless there are good reasons for each,
> and there isn't a strong reason to omit var() when you're not using
> any other functionality, so I don't allow it.

I'm not convinced restriction is worth the cost. Imho a bare --foo
should be valid as a variable use. If fallbacks are needed, then they
can be provided with functional notation.

If I was designing from scratch, we could have
   width: --foo;
   width: fallback(--foo, 20px);
but failing that I guess
   width: --foo;
   width: var(--foo, 20px);
is fine.

>> Why not something like "v()" as a shortcut (people using jQuery and stuff
>> are used to such shortcuts!)?
>
> While I highly value terseness in CSS and promote it whenever
> possible, it must be balanced against other concerns, like readability
> and understandability.  Single-letter names are generally a bad
> tradeoff here - they only save a little bit, but they make it much
> more difficult to tell what's being referred to.  The name "var()" is
> already abbreviated from "variable()", but it's a pretty unambiguous
> cut, and anyone working in the web platform is already familiar with
> "var" from JS.

Agree with this point.

~fantasai

Received on Thursday, 18 February 2016 03:28:48 UTC