RE: [css-variables] Why so inefficient?

> De : fantasai [mailto:fantasai.lists@inkedblade.net]
> 
> 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.

+1

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

+1

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

Brian and I suggested

   width: $(--foo||--bar||20px)

which is much nicer than

    width: var(--foo, var(--bar, 20px))

and is not weird like

   background: var(--header-background, url(a) left center no-repeat, url(b) repeat);
   background: $(--header-background || url(a) left center no-repeat, url(b) repeat);

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

+1

Received on Thursday, 18 February 2016 04:23:47 UTC