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

Re: [Css Variables] Variable Declaration Blocks

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Mon, 06 Oct 2008 11:16:20 -0700
Message-ID: <48EA55F4.7070205@terrainformatica.com>
To: Garrett Smith <dhtmlkitchen@gmail.com>
CC: Mike Wilson <mikewse@hotmail.com>, Chris Miller <chris@blinkbox.com>, www-style@w3.org

Garrett Smith wrote:
> On Mon, Oct 6, 2008 at 9:29 AM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>   
>> Mike Wilson wrote:
>>     
>>> I agree with you Chris and I'll add a few bits to (2):
>>>
>>>       
>>>> Andrew Fedoniouk wrote:
>>>>         
>>>>> 2) Why they are variables and not constants?
>>>>>           
>>> I'll reverse the question and ask why shouldn't everything in CSS be
>>> constants then? The same reasoning could be applied to the current CSS rule
>>> scheme and we could have "first rule wins"
>>> for everything, and no CSSOM modification after loading. We
>>> could even lock down script modification of HtmlElement.class
>>> and HtmlElement.style so all style and layout could be settled
>>> once and for all during load-time.
>>>       
>> Sorry but this "why not?" of yours is not an answer on the first one:
>> "Why they are variables and not constants?"
>>
>>     
>>> Personally I wouldn't want it to function this way, maybe some
>>> would, and I'd like to see variables use the same scheme as the
>>> rest already do.
>>>
>>> Talking about "run-time" modification of styles we already have
>>> f ex the following support in current implementations that will
>>> all lead to dynamic update of style/layout on elements:
>>>
>>> - change class on an HTML element through DOM
>>> - change properties on rule through CSSOM
>>> - add/remove rules through CSSOM
>>> - load a new style sheet through CSSOM
>>> - element style inheritance of changes by above operations
>>>       
>> So why do you need more here?
>> What *practical* task of yours does require variables to be in the
>> list?
>>
>>     
>
> I've worked on two applications that require cobranding.
>
> One used a strategy for that. One principle of patterns is
> "encapsulate the parts that vary," right?
>
> One part that varied was the colors.
>
> ..form-bg {
>   background-color: #f3f3f3;
> }
>
> ..form-color {
>   color: #333;
> }
>
>   

@const FORM-BG: #f3f3f3;
@const FORM-COLOR: #333;

@import rest.css

where the rest.css has following:

.form-bg {
  background: @FORM-BG;
}

.form-color {
  color: @FORM-COLOR;
}

That is typical case of parametrization by constant.
See: http://wiki.csswg.org/ideas/constants

So is the question: do you need constants or variables?



>>> Not offering run-time updates for variables would feel poor considering
>>> the above list, especially since composite/complex variables have the
>>> potential to become a main design element in future CSS.
>>>       
>
> Would "run-time updates" would seem like a big overhead.
>
> The CSSOM is less than ideal for a few reasons:
>  * not cross-browser (one needs an adapter to traverse, read, and modify).
>  * long, like NS4 API document.styleSheets[0].imports[0]..., there's
> no way to simply:
>  * find Rule by selectorText:  e.g. - DIV.big,*>span - is a valid
> selector, that might exist in a stylesheet. trying to search for
> div.big is not so simple.
>
> Mike Wilson stated a problem:
> [How to] change the background color on a number of (different kinds
> of) elements [?]
>   
Do you mean something like following (jQuery):

$(".foo").background("#334455");

?

-- 
Andrew Fedoniouk.

http://terrainformatica.com
Received on Monday, 6 October 2008 18:17:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:15 GMT