Re: [css-variables] ...let's change the syntax

Thank you both for clarifying further, I think I was going off the broken
capabilities of other parsers for interpolating vars with units.

I was aware about the retaining of the '--' with the new syntax, however I
was referring to the discussion regarding removing it. I can only assume
this was to simplify the syntax as much as possible.

It does seem however this syntax is going to be one of the most complex
from all the other syntaxes out there from Less, Sass, Stylus - I am aware
that the issue is a lot more complex than provided by these preprocessors
however rushing out specification changes last minute surely should allow
for some further flexibility for changes? I'm not after the shortest syntax
just questioning the last minute change really.

Custom identifiers should be clear enough without the use of var() I think,
I can see the risk however enforcing the double dash, I think adds enough
visibility to simplify the syntax of var(). As François stated the current
format would require:
  width: calc(--profile-height * 1px);

This to me seems much neater and easier to remember than:
  width: calc(var(--profile-height) * 1px);

On 29 March 2014 22:52, Tab Atkins Jr. <> wrote:

> On Sat, Mar 29, 2014 at 3:31 AM, Jonathan Kingston
> <> wrote:
> > Hi All and Tab Atkins jr,
> >
> > After careful review of the following message, I think I get the
> motivation
> > for this change a lot more than changing the syntax for variables.
> >
> >
> > Would it be worth instead of dropping the "--" prefix when in "var()"
> scope
> > dropping the use of "var()" when and where the parser could cope?
> Note - we don't drop the -- prefix when putting a custom property name
> in var().  Your examples below acknowledge this, so you may already be
> aware.
> > So for example, the following would be an issue
> >   height: --profile-image-heightpx;
> > So var would be used:
> >   height: var(--profile-image-height)px;
> >
> > However this would be fine:
> >   color: --profile-heading-color;
> >
> > This would give a similar feel to variable interpolation in many other
> > languages and template engines - it may also break the boundaries more of
> > users thinking it's main use is for variables.
> Unfortunately, this isn't great.  There are already a few places in
> CSS that accept <custom-ident> values, which technically allow
> precisely this syntax, and so there would be ambiguity.
> We could potentially disallow <custom-ident> from having a -- prefix,
> so there was no ambiguity, but then we're splitting syntax hairs,
> which tends to be very confusing for authors.  (Having to remember
> that X values uses the Y grammar, but not quite, because it excludes Z
> and W, is very difficult for people in practice, though it always
> sounds like it should be easy.)
> There's also the fact that a plain ident doesn't "jump out" very much,
> at least not as much as a function like var().  This is one of the
> benefits of var() - it's *immediately obvious* when you're using a
> variable, which is perceived as a benefit.
> Finally, even if we allowed this, we'd still need to *also* allow
> var(), so that you could do things like fallbacks.  Having two
> syntaxes for doing the same thing is another thing that leads to
> confusion for authors, and we try to avoid it when we can unless
> there's a really good benefit.
> ~TJ

Received on Sunday, 30 March 2014 01:05:50 UTC