W3C home > Mailing lists > Public > www-style@w3.org > May 2012

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 28 May 2012 08:57:28 -0700
Message-ID: <CAAWBYDBXBR0gzXoi8+2XCt_XzuBGqGBnKVPhgRx3UUz=Gb6fdg@mail.gmail.com>
To: John Daggett <jdaggett@mozilla.com>
Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, www-style@w3.org, "L. David Baron" <dbaron@dbaron.org>
On Sun, May 27, 2012 at 5:44 PM, John Daggett <jdaggett@mozilla.com> wrote:
> 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.

Argh, sorry, I've got some commits pending at work that I haven't
pushed yet.  I've reverted it to "whatever the 'value' production

> The first sentence is somewhat absurd, there's nothing "unrestricted"
> about this.

Even with the old definition you're quoting, that's pretty darn
unrestricted.  You can make up units or functions, put as many values
as you want, in any order, etc.  With the new (/even older)
definition, it's even more unrestricted.

> 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);

This is well-defined by the processing rules and by CSS's core syntax.

var-foo contains an ident with the value "bar".
var-family contains an ident with the value "var(foo)".  This is *not*
a function, and it is *not* a reference to the foo variable.
font-family thus contains two idents, with the values "Modern" and
"var(foo)", after the variable is processed.

> Or consider another example:
>  var-family: counter\(foo\);
>  font-family: Modern var(family);

Same deal - var-family contains an ident with the value "counter(foo)".

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

No, you can't.  It's only an ident, never a function.  This might be
somewhat hard to read from the Core Grammar, but it's there, and I've
also captured it in Syntax.  Functions only happen when an ident is
followed by a literal paren.  An escaped paren is just an escaped
character, part of the ident production.

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

It's now defined (though not yet pushed to the public draft) that it
accepts anything that matches the 'value' production.  This is
precisely the allowed production for property values *anyway*, per the
Core Grammar, so we're good.

WebKit still needs to change a bit here - we use the more restricted
Appendix G definition of valid property values, unfortunately.  But
it's not a big change.  You just have to follow a different grammar.
They're both written in the same language.

Received on Monday, 28 May 2012 15:58:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:59 UTC