Re: WebKit now supports CSS Variables

On Jun 24, 2008, at 5:00 PM, Andrew Fedoniouk wrote:

> Daniel Glazman wrote:
>> No, seriously, nobody here thinks of making the parser extensible by
>> variables declarations. So the rules above _are_ all valid and the  
>> only
>> option is value resolution after parsing. If you don't do that, then
>> you have constants, not variables. Because you will never be able to
>> assign again the variable's value since it's evaluated at parse  
>> time !
> Daniel, could you explain why do you need to "assign again the  
> variable's value"?
> What are use cases? If there are any then what stops you of updating  
> styles
> in current implementations by using JS?
> @const and @var handling have significantly different processing  
> models.
> @const handling happens at parse time and @var is getting evaluated  
> at runtime.
> That is significant shift. E.g. 4bits are required for representing  
> most of
> enumeration attributes in current CSS. @const is not changing this  
> requirement.
> And @var handling requires significantly more - in memory and CPU  
> senses.

No it doesn't.

The back end CSS declaration simply holds a chained list of terms  
constituting the unresolved expression.  The medium-specific front end  
can hold a cache from unresolved declaration to the resolved medium- 
specific version of the declaration.  The build-up of the medium- 
specific cache can be done lazily.  In an absolute worst-case scenario  
I suppose you would double the memory consumed by declarations, but  
these comprise an utterly insignificant portion of a page's overall  
memory use.


Received on Tuesday, 24 June 2008 22:10:27 UTC