- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Sat, 12 Feb 2011 05:08:24 +0100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: www-style list <www-style@w3.org>
* 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