Re: CSS Variables Draft Proposal

* Tab Atkins Jr. wrote:
>I'm not sure what term I *do* want, though.  The mental model is that
>the stuff you put into a variable have to be "values".  You can't put
>a unit in and expect to use it as a unit, for example, the "@var $foo
>px;" is perfectly fine if used as a keyword.  This shouldn't be hard -
>the intent is just that you can't store a "partial value" in a
>variable and then compose it with something else to get a whole value
>(so you can't do something like "@var $foo px; p { width: 200$foo;
>}").
>
>I heard conflicting statements about whether "token" was correct here,
>so I just avoided the issue and used a different word.  What is the
>correct term?

If you want a variable declaration to start with `@var` and end with `;`
then the only way you can define it that does not require changing the
core syntax is through a subset of `any*` with the error handling rules
that currently apply to unrecognized at-rules. `any*` corresponds to
specific sequences of tokens, not arbitrary sequences of tokens, so it
would be wrong to simply say "tokens", you would have to either use
`any*` or define some subset of `any*`. This follows directly from the
rule `at-rule : ATKEYWORD S* any* [ block | ';' S* ];`.

The core syntax and error handling rules already define what is allowed
at the most and how it is processed, you can only impose restrictions
that go beyond it and clarify requirements (for instance, parsers are
required to treat a style sheet `@var $example rgb(0,255,0` as if `)`
and `;` occured at the end of the sheet; you would have to make sure to
define things consistent with that invariant, or change that invariant).

Style sheets are sequences of tokens. Applying the parsing rules would
tell you which parts of the style sheet are to be interpreted as @var
rules and which parts are variable references and variable expansions
would be sequences of tokens as they occur on the style sheet or as im-
plied by the error handling rules. Similarily, since style sheets are
sequences of tokens, you would have to define variable substitution in
terms of token sequences since that is what, say, property values are
made from.

To illustrate: at the top level, if you see something that looks like
"@var" you take that and locate the end of the at-rule. That gives you
some sequence of tokens. Then you check whether these tokens make up a
valid @var rule, possibly inferring omitted tokens like in the example
above, if it is not valid then you ignore it, otherwise you dissect it
into variable name and value (and type whatever else there is in your
proposal) wich gives you a sequence of tokens that make up the value.

That is the same as you do for, say, property values, you look where
the value starts, find its end, and then see if the token sequence is
something you recognize, if not you drop it, otherwise you analyze the
value further like "these IDENT tokens make up a font-family name" and
so on and so forth.

Since you need IDENT tokens (or strings or whatever) to recognize a
font-family name, you need to define how you get from $variable to such
IDENT tokens. So, in the abstract data model you are dealing with tokens
while at the grammar level you are dealing with subsets of `any*`. That
is inevitably so because CSS is defined in terms tokens and, as far as
conformance goes, ";" at-rules allow only `any*` token sequences.

Avoiding your "width: 200$foo" is a simple matter of specifying that
variable substitution does not change tokens, then that would be the
same as, say, "width: 200/**/px" which is never parsed into a length as
a length is a DELIM or NUMBER but there you have a NUMBER followed by a
COMMENT followed by an IDENT.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Tuesday, 15 February 2011 03:24:31 UTC