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: Tue, 29 May 2012 13:49:01 -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: <658263969.23011131.1338324541642.JavaMail.root@mozilla.com>
Tab Atkins Jr. wrote:

> > 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.
> Careful where you point those accusations, John.  If I were being
> convenient to our implementation, I'd have stuck to the "term"
> production in Appendix G, which is what our experimental
> implementation actually uses.

Fine.  You seem to be taking an approach based on a formal grammar
when CSS parsing rules are based on a combination of formal syntax and
parsing rules described in text.  Using a formal grammar will be a
natural fit for some implementations, for others it won't.  I don't
see that the <value> type is something that is intuitively clear to
authors nor do I think it's a great idea to be doing validation in two
places, once in the definition and again in the use.

> > 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);
> I think you need to read the grammar more closely.  That's a perfectly
> valid <value>.  It tokenizes as NUMBER IDENT DIMENSION.
> (If it was invalid there, then it would *also* be invalid inside of
> calc(), since the interior of a function is just another <value>.)

Ok, which grammar description should I be reading here?  The 2.1
syntax defines an ident token as not beginning with '*' as a start
character.  As far as I can tell, the expression syntax for calc() is
only defined in CSS3 Values and Units.  Can you point me at the
specific specs that allow '*' to parse as IDENT?

>From my reading of the CSS3 Values spec, the contents of a calc()
expression seem very specific to that context, I'm puzzled how you can
claim that the expression syntax is "just another <value>".

> > 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.
> It's roughly equivalent to checking that the value of any other
> property conforms to the property's grammar.  Variables properties
> just have a much more wide-open grammar than any other property.

It's not, since the value will be checked *twice*, once using some
hard-to-define grammar of *all* CSS values and then in the context of
a specific property.  I think trying to define a formal grammar for
all CSS values will be very error-prone and unlikely to be
interoperable across user agents.


John Daggett
Received on Tuesday, 29 May 2012 20:49:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:17 UTC