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

Re: WebKit now supports CSS Variables

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Tue, 24 Jun 2008 13:25:41 -0700
Message-ID: <48615845.2050700@terrainformatica.com>
To: Francois Remy <fremycompany_pub@yahoo.fr>
CC: CSS 3 W3C Group <www-style@w3.org>

Francois Remy wrote:
>
> My first idea was to implements constants, too.
> But I think that it's good to have an "edit" feature so we can write 
> more complex code in the future.
>
> Currently, this is not the main idea to allow CSS! or another thing 
> that can have benefits of variables.
> But if we'll implements these (of others things we don't have thoug 
> before) in the future,
> we should implements variables now so we are sure that all is possible 
> in the future.
>
> It's also a benefits for JavaScript developers.

JavaScript is already capable to change styles. You already can do:

for-each$( td.something ).style.background-color = "red";

in one form or another. I see no principal difference of defining the 
same statement
as  document.styles.variables.setValue( "name", "red" );

So is the question: why do you need exactly variables? Who and when is 
supposed to mutate them?

>
> Fremy
>
> ========================================================|
> |    PS : |
> |    BTW, I don't like CSS! because CSS is for styling not for 
> scripting. |
> |    Javascript/XMLScript is here for scripting |
CSS, in particular selectors,  has limitations that cannot be solved
in terms of static system of declarations. For example following 
declaration:

a.master
{ 
    hover-on!:  $(a.dependent):hover = true;
    hover-on!:  $(a.dependent):hover = false;
}

will cause highlighting of all a.dependent elements in the document when 
you move
mouse over the a.master element. It is simply not feasible to define 
this in terms of system of
static CSS rules.

Like we it or do not this will be there anyway. In one form or another.
And yet CSSS! is the only thing so far that gives some sense to CSS vars.
At least I cannot see why mutable CSS vars are needed. Constants - yes - 
quite useful.

-- 
Andrew Fedoniouk.
http://terrainformatica.com

> ========================================================|
>
> --------------------------------------------------
> From: "Andrew Fedoniouk" <news@terrainformatica.com>
> Sent: Tuesday, June 24, 2008 9:34 PM
> To: "David Hyatt" <hyatt@apple.com>
> Cc: "Håkon Wium Lie" <howcome@opera.com>; "www-style list" 
> <www-style@w3.org>
> Subject: Re: WebKit now supports CSS Variables
>
>>
>> Is there any use case for CSS variables to be mutable (not constants)?
>>
>> As far as I can see the only difference from CSS constants ( 
>> http://csswg.inkedblade.net/ideas/constants )
>> is the ability to change values in runtime (from script).  So is the 
>> question above.
>>
>> There is clearly a need for such thing as CSS vars/consts, but 
>> particular model (vars vs. consts) is still debatable.
>> At least for me. CSS consts as parse time entities allow to define 
>> shortcut attributes too, btw.
>>
>> On other side if we already on the way of moving CSS declarations 
>> from static form to something that is getting
>> evaluated at runtime (early birds: MQ, calc()) then CSS-vars fit the 
>> model. As a logical corollary I think it will be some
>> sort of dynamic (behavioral?) extensions of  CSS that will allow to 
>> manipulate values of variables:
>>
>> select#color-preferences
>> {
>>   on-value-changed! : var(theme-back-color) = #ff0000,
>>                                  var(theme-back-image) = 
>> url(red-back.jpg);
>> }
>>
>> (That is CSSS! - http://terrainformatica.com/htmlayout/csss!.htm )
>>
>> I mean that: if we say "A" (variables in CSS) then we should be ready 
>> to pronounce "B"
>> ( some sort of dynamic [sub-]language in CSS ). Otherwise CSS-vars as 
>> mutable entities
>> appears as overkill if to compare them with @const.
>>
>> -- 
>> Andrew Fedoniouk.
>> http://terrainformatica.com
>>
>>
>
>
Received on Tuesday, 24 June 2008 20:26:36 GMT

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