Re: WebKit now supports CSS Variables

David Hyatt wrote:
> On Jun 26, 2008, at 9:09 PM, Andrew Fedoniouk wrote:
> 
...
> 
>> One more question:
>>
>> @variables
>> {
>>  ThemeSomething: #fe8d12;
>> }
>>
>> body
>> {
>>  background: var(ThemeSomething) green;
>> }
>>
>> Question is: where var(ThemeSomething) will go?
> 
> The CSS declaration contains a property/value pair for "background."  
> The shorthand is not expanded.  None of this is in the spec., but in my 
> implementation I have a special value that represents the whole 
> unresolved right side, a CSSVariableDependentValue.  If you ask for its 
> cssText you'll get the raw expression, e.g., "var(ThemeSomething) 
> green."  I don't think there's any need for this class to be exposed... 
> it can just be a CUSTOM value in the CSS OM.

So you have in runtime following:

1) global collection (name/value map) of variables and
2) background: non-parsed("var(ThemeSomething) green");

This means that you should interpret (parse/evaluate) that
non-parsed() thing each time when you need background attributes.

Am I correct in my understanding how it works?

Otherwise you would need to maintain list of all attributes in all rules
where this variable is participating and while changing that value
to walk through the list and re-parse that non-parsed thing again.

Correct?

> 
>>
>> What will happen if variable will be changed from "#fe8d12"
>> to, say, "url(yeek.png)" in runtime?
>>
> 
> Any calls to a variable remain unchanged in the back end declarations.  
> The medium-specific front end information will update to try to resolve 
> the new value (and when that fails, the property/value pair will be 
> ignored.)
> 
> I encourage you to write tests against the WebKit implementation and try 
> it out.  You might answer your own questions and/or find bugs that way 
> that would help us refine the implementation.

I have a feeling that you are getting this as a sort of offense from my 
side. Sorry if I created such an impression. Not intentionally.

I am looking on this from implementation point of view. So are these 
questions. Trying to decide shall I implement it or not?

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...

If it is solely for JS... I think in particular case
it is already not so difficult to implement routine that will
walk through the CSSOM (or DOM) and update particular rules/elements.
Or probably I have missed something in principle?

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Friday, 27 June 2008 04:13:45 UTC