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

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

From: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
Date: Wed, 30 May 2012 08:36:38 +0800
Message-ID: <4FC56B96.2020703@csail.mit.edu>
To: WWW Style <www-style@w3.org>
(12/05/30 6:20), L. David Baron wrote:
> It basically accepts any token stream that has balanced quotes,
> parentheses, brackets, and braces, and doesn't contain a semicolon,
> <!--, or --> at top level (i.e., not quoted, parethesized, etc.).

Nitpicking: A balanced quote formed by two BAD_STRINGs can't be a <value>.

> (I'm not sure we want the <!-- and --> restrictions, though.)

And also I'd mentioned[1] that we should exclude more DELIMs here,
including at least '!' and perhaps '#' and '@' and all other characters
not yet used in CSS. Otherwise, we should have clear and normative text
about how the "! important" case is handled. Either is fine. It just
needs to be more well-defined.


(12/05/30 7:10), Tab Atkins Jr. wrote:
> 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.

While I agree with most of what you said, I would like to contest with
this statement. Even if this Core Grammar (by which I mean the grammar
rules there) is over a decade, it is either non-normative or has
conflicts with and trumped by the the rules as described in text. I
suppose that's the reason why a bunch of tests in this area[2] were
marked invalid.

To be more precise, I think what the prose describes and what the test
suite tests is

  | any       : [ IDENT | NUMBER | PERCENTAGE | DIMENSION | STRING
  |           | DELIM | URI | HASH | UNICODE-RANGE | INCLUDES
  |           | DASHMATCH | ':' | ']' | ')'
  |           | FUNCTION S* [ any | unused | ']' | '}' ]* ')'
  |           |      '(' S* [ any | unused | ']' | '}' ]* ')'
  |           | BAD_URI  S* [ any | unused | ']' | '}' ]* ')'
  |           |      '[' S* [ any | unused | ')' | '}' ]* ']'
  |           ] S*;

(Basically balanced quotes, parentheses, brackets, and braces. Firefox12
and IE9 implement parenthesis matching for BAD_URI. I am not sure about
other browsers. Also, I am not an expert in grammars so the above might
not be valid.)

instead of

  # any       : [ IDENT | NUMBER | PERCENTAGE | DIMENSION | STRING
  #           | DELIM | URI | HASH | UNICODE-RANGE | INCLUDES
  #           | DASHMATCH | ':' | FUNCTION S* [any|unused]* ')'
  #           | '(' S* [any|unused]* ')' | '[' S* [any|unused]* ']'
  #           ] S*;

In summary, I think this is good enough (but we should still change it
to be more reality-matching) but I'll prefer if we can make it clearer
in css3-syntax and references that part instead of this.


(12/05/30 3:10), Sylvain Galineau wrote:
> [Tab Atkins Jr.:]
>> 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.
>
> No one argues that it's not less restricted. But there *is* a
> restriction and I think it is suggested that in a specification words
> such as 'unrestricted' are best used to describe an absolute state
> vs. using them as a loose comparative e.g. as a marketing department
> would use 'unlimited' to describe certain flat pricing schemes.

For this editorial matter, I'd like to say that I do also think there's
a problem here: the "you".

CSS2.1 has 10 "you"s, 7 in non-normative sections (mostly Chapter 2), 2
in example-like sentences (i.e. "e.g." and "For Example"), 1 in an
example. So, I recommend we move this kind of description into an
informative note or the introduction section.

As a specification, I think CSS2.1 is sloppy enough and I would
recommend we use more "must", "should", "User Agent" and more
algorithmic description like the HTML spec (or the new css3-syntax).

[1] http://lists.w3.org/Archives/Public/www-style/2012Apr/0188
[2]
http://test.csswg.org/suites/css2.1/nightly-unstable/xhtml1/chapter-4.xht#s4.2


Cheers,
Kenny
Received on Wednesday, 30 May 2012 00:37:08 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:54 GMT