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


[John Daggett:]
> >
> > 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'm with John here; this sentence is OK as a casual spoken statement to
an audience during a CSS Variables 101. In a spec it just looks silly
as it's a) untestable b) vague c) redundant ('almost unrestricted' should
do, the 'completely' is unnecessary) and d) contradictory since it 
*is* then normatively restricted to a range of values. 

(Though I will admit I do enjoy thinking of a new Monty Python line 
every time I read this paragraph...)

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

Indeed. The 2.1 grammar allows property values to combine terms with operators 
so that would seem to be one CSS Variables restriction.

> 
> 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.
> 
That is my mental model as well, fwiw.

Received on Tuesday, 29 May 2012 17:02:53 UTC