Re: [css-variables] Putting it all toegether (syntax)

François REMY:

> 1.    $foo is a popular replacement-initiator token

Yes, it’s the best solution for string constants, which can even be used in selectors. That can only be done compatibly and reliably in preprocessors, not at compute time. We should leave ‘$’ to them.

> 4.    Often, prequels are important to understand a story

Add ‘@font-face’, ‘@page’, ‘string-set’, counters etc. I’d really like to stay with the concept of *user-defined keywords*, even if their names may be restricted.

> 5.    Why we don’t want { $foo: bar }
> 
> Secondly, this is breaking the core CSS grammar

Exactly, and since there are no *clear* benefits speaking in favor of it, I don’t understand why it’s still on the table.

> 6.    Why we need a prefix
> 
> However, if we don’t use the $ prefix, we have to restrict the names authors can give to their user-defined properties.

The question is whether this should be a whitelist or a blacklist. The former is future-proof, the latter isn’t. The whitelist can include wildcards, which is just prefix (or suffix or infix …) reworded.

‘x-’ is not really a safe prefix, because it might be used as a synonym for “horizontal” (alongside ‘y-’ and possibly ‘z-’ or ‘t-’). All known vendor prefixes are out, too, because in former times they were permitted to be used without initial hyphen (hence e.g. ‘mso-’). <http://wiki.csswg.org/spec/vendor-prefixes#known-prefixes> Also all other module monikers, e.g. ‘text-’, ‘font-’, ‘color-’, ‘background-’ …

However, ‘data-’, ‘var-’, ‘my-’, ‘const-’, … are all equally fine. The CSS WG may decide to use exactly one of them, but it doesn’t have to, because multiple ones would work, too.

Also, select keywords could be allowed explicitly, e.g. system color names.

> If variable names are constrained by a prefix, this becomes a no-brainer: 

Yes, but that doesn’t need to be a single non-alphabetic character.

> 7.    Variables should be consistent in name
> 
> Last but not least, many stated on this list that they din't like the fact a variable "changed" of name between the time it's been set and the time it's retreived.

That’s why I like the underscore, e.g.:

  set_var-foo: green;
  color: var-foo;

That’s of course more verbose than

  set_foo: green;
or
  var-foo: green;
and
  color: foo;
or
  color: $foo;

but less troublesome and it’s (a bit) less verbose than

  color: var(foo);
and
  color: $var-foo;

but it’s easier to extend later on.

I’m not sure, but I think the following, completely different approach has been suggested before already:

  :root {color: #123456 !set(foo);}
  bar   {background: #654321; /* default: fallback for non-supporting implementations */
         background: !get(foo); /* no extra fallback */
         background: #fa1bac !get(baz); /* with fallback if variable can’t be resolved */}

I just want to remind people that setting a variable, like getting it, doesn’t necessarily have to tangent the lefthand side of the colon.

Received on Tuesday, 5 June 2012 10:34:21 UTC