RE: New CSS variables syntax in latest WebKit


David Hyatt wrote: 
> I've added support for several of the proposed syntax ideas for CSS  
> variables to WebKit.

David, again a big thanks for working on this. This will be a great
and long-missed addition to CSS, whatever syntax and semantics that 
"win" in the end.

> For the rules, the following syntax works:
> @-webkit-define { ... }

This would correspond to @define after being blessed by an official
w3 recommendation I guess. I quite like "define" as its name is
quite intuitive wrt its behaviour, and it avoids any overloaded
interpretations of what to expect from something named as variable.
(I quite like "CSS variables" as the name of the spec though, so I
guess I'm not 100% consistent there ;-)

> For variable references, the following syntax works:
> (1) -webkit-var(foo)
> (2) =foo=
> (3) $foo
> One concern about using a symbol to represent a variable is 
> that there is no way to vendor-prefix it.

The ultimate goal is that these constructs become part of a w3c
recommendation, so for the "final" naming scheme we don't really 
need to take vendor-prefixing in account, right?


David Hyatt wrote:
> @define for print { ... }
> @variables print { ... }
> instead of
> @media print { @define { ... } }
> If we want variables to work inside @media blocks, we'd 
> basically have to relax the restriction that variables rules 
> must be at the start of the stylesheet.  (There is no 
> implementation hurdle to doing so...  
> this basically just comes down to syntactic preference.)

I think I would prefer both to have variables inside media 
blocks and to be able to declare variables anywhere in the
file. As long as the semantics are straight-forward for 
reference-before-definition scenarios I don't see any big
(But this is said with a lot of respect for things I may be


Daniel Glazman wrote:
> > (1) -webkit-var(foo)
> > (2) =foo=
> > (3) $foo
> > 
> > One concern about using a symbol to represent a variable 
> > is that there is no way to vendor-prefix it.  Then again, 
> > just using a symbol like = or $ looks nicer than the ugly 
> > "-webkit-var" notation.
> It also looks terribly more dangerous because some server modules
> already use such syntax for macro expansion on the server's side...
> Honestly, I think 2 and 3 are not a good idea.

This problem certainly exists, but I'm not sure how much 
attention we should give to it. I would prefer a short and 
intuitive syntax like $ and would welcome that some kind of
"damage estimation" be performed for the most popular 

That said, an observation is that WML is using $() for its
references so the server modules that serve WML may well not
use that for their own macros :-)... There may be other, better,

Best regards

Received on Friday, 22 August 2008 21:33:02 UTC