Re: WebKit now supports CSS Variables

On Jun 26, 2008, at 9:12 PM, Andrew Fedoniouk wrote:

> Honestly, both cases above appear as an overkill for such in  
> principle simple thing. I mean main motivational idea: "write value  
> once - use it everywhere by name".
>
> The only bonus of CSS @vars from CSS @const is the ability to change
> their values by script in runtime. I haven't heard anyone asking for  
> such a feature...

I tend to agree. Besides changing class names or assigning a normal  
(non var) value to the property with something like 'myDiv.style.color  
= "green"; ', one could also (presumably) assign a different var (or  
constant) with something like this:

myDiv.style.color = "var(ThemeColor2)";
// assuming it originally had a value of "var(ThemeColor1)"

On Jun 27, 2008, at 12:24 AM, David Hyatt wrote:
> WebKit just rebuilds all of its front end style information when  
> variables change (we do the same thing when style rules in a sheet  
> change).  Not the best thing to do performance-wise, so we'll  
> probably improve it in the future (possibly by maintaining such a  
> list yes).

If having variables instead of constants creates implementation or  
performance difficulties, it does not seem that important to do so.  
Constants would be plenty good enough.

By the way, I never got an answer from David on this one:

On Jun 24, 2008, at 9:38 PM, David Hyatt wrote:

> I am not averse to the idea of reusable property/value clusters.

How about variables that represent long strings of selector text?

I often have to right some rather complex selectors to make up for  
poorly written HTML, and then repeat large parts of them. Having a  
short variable to replace long selectors would probably be more useful  
to me than any other type of CSS variable. It also makes it handy when  
the HTML gets rewritten and the selectors need to be rewritten to  
match it.

Received on Friday, 27 June 2008 15:22:56 UTC