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

On Tue, May 29, 2012 at 1:49 PM, John Daggett <jdaggett@mozilla.com> wrote:
> 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 understand.  You *must* do validation at the point of use,
because you need to verify that the inserted value produces a valid
property value.

You may be misunderstanding just how loose the "value" production is.
The restrictions it places on values is pretty much the absolute
minimum we need to ensure things aren't crazy.  As David says, it
pretty much just disallows the value from containing a semicolon or
mismatched parens, braces, or brackets.  All of these are pretty
obviously necessary for reasons of basic stylesheet parsing.

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

Shit, I'm sorry, I meant to say DELIM.  Mental typo there.  NUMBER
DELIM DIMENSION.  That's a valid match for the "value" production.

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

Look at CSS2.1 chapter 4.  This is the actual Core Grammar that CSS
follows.  The part of the 'value' production that calc() matches is:

FUNCTION S* [any|unused]* ')'

The 'any' production is just the 'value' production minus {}-blocks
and at-keywords.  (The 'unused' production adds those back in to help
with grammar-based error-handling.)

Thus, since the contents of calc() match 'any', and 'any' is a subset
of 'value', a var property can contain the contents as well.

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

I'm pretty sure you're talking about something different than what I am here.

The var property grammar isn't hard to define - it's the 'value'
production in CSS2.1 chapter 4, which has been part of the Core
Grammar for over a decade.

I'm not sure what you mean by "define a formal grammar for all CSS
values", but I'm not doing anything that can be reasonably described
as that.

~TJ

Received on Tuesday, 29 May 2012 23:11:45 UTC