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

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

From: John Daggett <jdaggett@mozilla.com>
Date: Mon, 28 May 2012 18:46:41 -0700 (PDT)
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, www-style@w3.org, "L. David Baron" <dbaron@dbaron.org>
Message-ID: <337672226.22513953.1338256001316.JavaMail.root@mozilla.com>
Tab Atkins Jr. wrote:

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

The right side of a variable definition needs to conform to:

  <value>+ [ [ ‘,’ | ‘/’ ] <value>+ ]*

That's *not* unrestricted!  I think you're simply trying to emphasize
is that this can be any value allowed in CSS.  Just say that.  Saying
it's unrestricted is misleading and incorrect, there's no value in 
such a statement to either authors or implementors.

I also think the use of the term "value" is confusing in that section
since you're overloading it to mean both the entire right side of a
variable definition *and* a CSS value.

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

No, we're not good.

As David has already pointed out, that section of the Core Grammar is
informative, not normative. You seem to be shaping the spec to what's
convenient to implement for your user agent.  I don't see the value in
validating variable definitions against some intermediate production
within the grammar.  It's neither clear to authors, nor is it
something that's trivial to implement in all user agents.  It seems
inherently restrictive in weird ways.  For example, this seems to
disallow expressions used within calc functions [1]:

  var-foo: 3 * 25px; /* invalid, since doesn't fit the def'n of <value> */
  border-width: calc(var(foo) + 1em);

It also introduces *two* points of failure for an author, one in the
defintion, the other in the use.  I think it's much simpler to think
of variable definitions as blobs of tokens, they only need to be valid
in the context where they are used.  That way implementations don't need to
carry around some universal CSS value validity check that they don't
necessarily otherwise need.


John Daggett

[1] http://www.w3.org/TR/css3-values/#calc
Received on Tuesday, 29 May 2012 01:47:11 UTC

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