Re: WebKit now supports CSS Variables

David Hyatt wrote:
>
> 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.
Particular mileage may vary of course. 
The only thing that is known: current CSS uses enumeration attributes 
that require 2-5bits for storage.
Handling is trivial as with any other enumerations. CSS Varaibles simply 
require storage to be increased at least
to the size of pointer (32bits usually) plus additional handling of 
linked lists with all goodies like cache misses, etc.
Again that is not about particular implementations but rather about 
minimal requirements.
May I ask this question again? For the sake of what? How current JS 
scripts will benefit from this?

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Tuesday, 24 June 2008 22:45:21 UTC