- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Tue, 24 Jun 2008 15:00:20 -0700
- To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- CC: Håkon Wium Lie <howcome@opera.com>, Maciej Stachowiak <mjs@apple.com>, www-style list <www-style@w3.org>
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. So is my question: are there any benefits that are worth changing all this? -- Andrew Fedoniouk. http://terrainformatica.com
Received on Tuesday, 24 June 2008 22:01:14 UTC