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

On Mon, May 28, 2012 at 6:46 PM, John Daggett <jdaggett@mozilla.com> wrote:
> 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.

It's extremely unrestricted compared to normal CSS.  The sentence just
emphasizes that there's no particular grammar for the property, in the
sense that normal CSS properties have.


> 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 agree this is slightly confusing, but the Core Grammar production is
called "value". ^_^  Do you have a less confusing term I can put
between angle brackets for use that's still sufficiently general?


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

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.

Let's keep this to the actual text and proposals, rather than trying
to divine people's intentions through tea leaves.


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


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

~TJ

Received on Tuesday, 29 May 2012 17:37:30 UTC