W3C home > Mailing lists > Public > www-style@w3.org > September 2008

Re: [Css Variables] Variable Declaration Blocks

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Fri, 26 Sep 2008 10:20:14 -0700
Message-ID: <48DD19CE.7090903@terrainformatica.com>
To: Brad Kemper <brkemper.comcast@gmail.com>
CC: Mike Wilson <mikewse@hotmail.com>, www-style@w3.org

Brad Kemper wrote:
> On Sep 26, 2008, at 5:46 AM, Mike Wilson wrote:
>> Brad Kemper wrote:
>>> But if the author wanted it to act as a constant,
>>> where "first rule overrides later rules", he
>>> could add a keyword to that rule that would
>>> accomplish that by adding 1,000,000 to the
>>> specificity calculation:
>>     @define constant {
>>      mySimpleVariable: 5px;
>>      myComplexVariable {
>>          width: 5em;
>>          height: 5em;
>>      }
>>     }
>> But how would you treat a subsequent
>>  @define constant mySimpleVariable
>> assignment in the same document?
>> This is where Andrew wants the first clause to have
>> precedence and this means we either have to invent a
>> position-dependent specificity calculation or change
>> the cascade algorithm.
> In my view, if you added the keyword "constant" to the variable 
> definition, then it would act more like a constant, with the first one 
> taking precedence, and subsequent imported ones useful as default 
> values in case the first one is missing. As Andrew described. I don't 
> see any reason to fight against this; you can have your cake and eat 
> it too.
>> We already have !important for explicitly pointing
>> out a certain rule to have precedence.
> Not the same thing. If you have two rules in which !important is 
> applied to the same value with the same specificity, then the second 
> one wins. Which is opposite of how constants work. The whole idea 
> behind constants is that they are like variables that don't change 
> once declared. That is a useful thing to have.
I should mention following:

Adding @const'ants in the way they proposed  here 
does not change current basic principles of CSS architecture.

1) CSS rules is a list of static declarations. CSSOM does not count as 
it belongs to JS/DOM more than to CSS.
2) Once parsed selectors (and so specificity of rules) and attributes 
cannot be changed by CSS means. CSS declarations are constants by their 

Adding @const'ants is extremely easy to add to existing CSS parsers.

While parsing particular style sheet:

1) Parsing of style sheet happens in presence of so called parsing 
context that includes among
    other things reference to table of constants in parent style sheet 
(if any);

2) When you meet @const NAME: list-of-tokens; construction then add
    NAME/list-of-tokens to the table of consts for the sheet. If it is 
already there or is found
    in parent tables then do nothing.

3) When you meet constant insertion point ( e.g. @NAME ) then push back 
list-of-tokens found
    under the NAME (locally or in parents) into the parser. So parser 
will treat that
    list-of-tokens as if they were there.


That is really easy to do and it does not require any major changes in 
CSS grammar and operating principles.

If for some crazy reasons you need exactly variables that could be 
changed in runtime then you can use
CSSOM and modify rules there in the way you want.

Andrew Fedoniouk.

Received on Friday, 26 September 2008 17:29:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:39 UTC