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

Re: [CSS Variables] WebKit now supports variable declaration blocks

From: Brad Kemper <brkemper.comcast@gmail.com>
Date: Fri, 22 Aug 2008 12:47:26 -0700
Message-Id: <4F7935E6-A524-48FA-B817-4B368371A925@gmail.com>
To: David Hyatt <hyatt@apple.com>
Cc: "L. David Baron" <dbaron@dbaron.org>, "www-style@w3.org List" <www-style@w3.org>

It would be safe to ship with @-webki-variables and -webkit-var()  
though, until it is finalized, wouldn't it?


On Aug 22, 2008, at 12:36 PM, David Hyatt <hyatt@apple.com> wrote:

>
> On Aug 22, 2008, at 10:21 AM, L. David Baron wrote:
>
>> On Monday 2008-07-28 17:56 -0500, David Hyatt wrote:
>>>
>>> In the next WebKit nightly you will be able to try out CSS variables
>>> whose values are declarations.  Here is what the syntax looks like:
>>>
>>> @-webkit-variables {
>>>  simpleVariable: 5px;
>>>  complexVariable {
>>>      width: 5em;
>>>      height: 5em;
>>>  }
>>> }
>>>
>>> div {
>>>   background-color: green;
>>>   -webkit-var(complexVariable);
>>>   color: white;
>>> }
>>
>> So are these variables intended to be mutable later via script, or
>> intended to be constants?  (If the latter, should they really be
>> called variables?)
>>
>
> In the prototype, yes, they are intended to be mutable.
>
>> If they're supposed to be variables, it seems like it's impossible
>> to get the following combination to work correctly:
>> * cascading order
>> * CSS object model, which only allows storing one value per
>>  property per declaration block
>> * dynamic changes to complex variables.
>>
>
> Yes, you hit on something subtle here.
>
> In the WebKit prototype, the variable declaration blocks allow  
> redundant property storage.  If you use iteration (the item method  
> on CSSStyleDeclaration), you will be able to see the multiple  
> properties.  If you use getProperty*** methods, you'll get the first  
> property.
>
> When variable declaration blocks are resolved you then inject those  
> properties in in order.
>
> So to answer your question, the part that I suppose works  
> "incorrectly" is that we allow storing more than one value per  
> property in variable declaration blocks.
>
>> In particular, if the complex variable can be changed later, I'm not
>> sure how to reflect in the CSS object model that there's a
>> declaration block a declaration like:
>>
>> @define {
>> complexVariable {
>>   color: blue;
>> }
>> }
>>
>> p { var(complexVariable); color: green; }
>> q { color: purple; var(complexVariable); }
>>
>> such that p elements are green, q elements are blue, but if we
>> dynamically change complexVariable to no longer declare the color
>> property, q elements would change to purple.  (And consider
>> especially dynamic mutation of sheet.cssRules[i].style.color on the
>> p and q rules, which is already permitted.)
>>
>> Are these complex variables intended to be mutable, or are they
>> really constants?
>>
>
> Mutable (although this doesn't work right for declaration blocks in  
> WebKit yet).  Right now there is no API for obtaining a variable  
> declaration block's CSSStyleDeclaration, so at best all you can do  
> is change the entire value of the variable (and not components of  
> the declaration block).
>
>>> As I stated in a previous post, WebKit also currently supports the
>>> double equals syntax and the dollar sign syntax for referencing
>>> variables, so =complexVariable= and $complexVariable also work.
>>
>> This seems a bit dangerous in case this syntax is not chosen for
>> variables, but is then used in CSS for something else later on.
>
> Yes, I have no plans to ship a product with CSS variables support  
> unless the syntax is largely finalized.  What's in WebKit nightlies  
> is a prototype. Nothing more.
>
> dave
> (hyatt@apple.com)
>
>
Received on Friday, 22 August 2008 19:48:17 GMT

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