Re: css constants

----- Original Message ----- 
From: "Daniel Glazman" <daniel.glazman@disruptive-innovations.com>
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: "fantasai" <fantasai.lists@inkedblade.net>; <www-style@w3.org>
Sent: Tuesday, August 28, 2007 2:15 AM
Subject: Re: css constants


> Andrew Fedoniouk wrote:
> 
>> Why "only if .. can be changed"? Could you explain real world scenario?
> 
> Sure. Imagine the following sheet, based on hypothetical @const
> at-rule and a const() function notation.
> 
>    @const mycolor #123456;
> 
>    h1 { background-color: const(mycolor); }
> 
>    #foobar { color: #123456 ; }
> 
>    div.foo > p + h2 { border: solid thin const(mycolor) ; }
> 
> Now, when the page is loaded, you want to change programmatically
> the constant into something else. Then OF COURSE you want the first
> and last rule to be updated and NOT the second one. So what you
> really want to tweak here is NOT the style rules themselves BUT
> the @const definition. See what I mean ?
> If you don't do that, having constants in CSS is mostly pointless
> and only a minor help at authoring time.
> 

Hi, Daniel,

I understand the idea of dynamic updates I even can imagine 
that it can be used somehow but I cannot recall any 
real life situation where I need such client side style manipulations.
Do you have any site or use cases where it might be needed?

@const (as a constant) in contrary helps a lot when UI is 
composed from many pieces/components that use their own
style sheets - some config.css has schema defintions used in many
places.

And yes, in principle such @const can be made by using some
specilaized prepocessor but this will not work for cases when 
there is simply no such preprocessor. E.g. when css is stored locally
or in cache.

Andrew Fedoniouk.
http://terrainformatica.com

Received on Wednesday, 29 August 2007 01:57:14 UTC