Re: CSS Variables Draft Proposal

* Tab Atkins Jr. wrote:
>The syntax is `@var`, followed by whitespace, followed by the variable
>name (which must start with a $, and then follow the IDENT
>production), followed by whitespace, followed by an arbitrary series
>of CSS tokens, capped by a semicolon at the end.
>
>(I want to impose stricter requirements on variables values than just
>"a token stream", but it's not immediately clear how to do so.  See
>the Typed Variables section later down, though.)

I don't understand the discussion about this. The Core Syntax already
takes care of many of the things people brought up, it would parse as

  ATKEYWORD (@var)
  S*
  DELIM ($)
  IDENT (name)
  S*
  any+
  DELIM ';'

Here `any` cannot be a block (and I am assuming you cannot put some
block as the last thing either, although that would be allowed by the
core syntax) it cannot be empty (that would be allowed by the core
syntax aswell, but there would seem little reason to allow it) and it
cannot be something like "url(" or ")" as that is no `any`, unless the
core syntax was changed. Also note that `$/**/name` would be allowed.

The only issue might be the effect of auto-correcting certain errors
like pretending that all "open constructs" have been closed when you
hit the end of a style sheet prematurely, but there seems no obvious
issue there. So an implementation would parse the style sheet, take
note of variable declarations, building a dictionary

  name1 => any+,
  name2 => any+,
  ...

Then you take the parse tree generated in the first pass, replace all
instances of the two-token sequence that make up a variable reference
with the token sequence in the dictionary and then proceed as usual,
possibly recursively if you allow variable references in variable de-
clarations. That would be the high level effect, obviously you'd
optimize that. The only issue there is how you handle white space.

Some of the issues that have been mentioned would be a problem if the
core syntax was changed so you can use arbitrary tokens instead of the
ones allowed by `any`, but there seems no reason to do that, especially
considering implementers have yet to produce a fully conforming parser.

Note that it would be possible to further constrain `any` values to
avoid some odd looking cases, like `@var $x /;` but I am not sure that
would be worth it.

>Using a variable that hasn't been declared is a syntax error.  (It's
>valid to use a variable that hasn't been declared *yet* - the
>declaration may appear later in the stylesheet, or in another sheet
>entirely.)

That would of course make things a bit more complicated as you'd then
have to keep unparsed syntax around. That's probably not very popular.
-- 
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 Saturday, 12 February 2011 04:08:55 UTC