Re: [css-variables] allowed syntax of variable values

The current editor's draft definition of variable definitions [1] describes
the syntax as:

  var-<ident> :  <value>+ [ [ ‘,’ | ‘/’ ] <value>+ ]* 

where 

  <value> = [ <number> | <percentage> | <dimension> | <string> | <ident> | <url> | <function> | <hash> ]

But then there's a paragraph that states:

  The valid possible values of a variable property are almost
  completely unrestricted. A variable property can contain
  anything that is valid according to the value production in the
  CSS Core Grammar. The values do not have to correspond to any
  existing CSS values, as they are not evaluated except to
  replace variables occurring within them until they are actually
  referenced in a normal property with a variable. 

The first sentence is somewhat absurd, there's nothing "unrestricted"
about this.  But I think the real problem here is that there are CSS
properties where distinguishing between value types has to
be done in a property-specific production.

Example:

  var-foo: bar;
  var-family: var\(foo\);
  font-family: Modern var(family);

The definition of 'font-family' above is equivalent to which of the
two alternate definitions below?

  font-family: "Modern bar";
  font-family: "Modern var(foo)";

Or consider another example:

  var-family: counter\(foo\);
  font-family: Modern var(family);

Is the font-family declaration above valid?  The problem here is that
you can capture counter\(foo\) as either a function or as an ident. 
If it's a function, then the font-family syntax will treat the value
above as invalid, rather than treating it as equivalent to:

  font-family: "Modern counter(foo)";

I really think you need to define the syntax of the value as being
something much lower level, as just a bag of uninterpreted tokens
except for var() evaluations with some very basic well-formedness
rules to deal with matched quotes, braces, etc.

As it stands now, the current definition requires all parsers to have
a general value production that behaves consistently.  My hunch is
that this would be a big rathole of inconsistency across implementations
for very little benefit (i.e. the benefit of having validity checking
in both the variable definition and in the use).

Regards,

John Daggett

[1] http://dvcs.w3.org/hg/csswg/raw-file/5831f7561bd1/css-variables/Overview.html#defining-variables

Received on Monday, 28 May 2012 00:44:33 UTC