- From: David Hyatt <hyatt@apple.com>
- Date: Tue, 24 Jun 2008 17:09:47 -0500
- To: Andrew Fedoniouk <news@terrainformatica.com>
- Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, Håkon Wium Lie <howcome@opera.com>, Maciej Stachowiak <mjs@apple.com>, www-style list <www-style@w3.org>
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. dave (hyatt@apple.com)
Received on Tuesday, 24 June 2008 22:10:27 UTC