Re: [css-variables] Hidden costs.

>-----Original Message----- 
>From: Tab Atkins Jr.
>Sent: Wednesday, February 16, 2011 12:52 PM
>To: Andrew Fedoniouk
>Cc: www-style@w3.org
>Subject: Re: [css-variables] Hidden costs.
>
>On Tue, Feb 15, 2011 at 8:25 PM, Andrew Fedoniouk
><andrew.fedoniouk@live.com> wrote:
>> The problem is that no one of Web designers actually asked about exactly 
>> CSS
>> Variables
>> (run-time interpretable entities). Except of authors of this bright 
>> idea -
>> Daniel Glazman et al.
>> of course. But there are a lot of requests for CSS Constants (parse time
>> macro variables).
>> Just note various existing CSS macro/preprocessors and absence of 
>> anything
>> even close to CSS variables (they can be modeled in principle by JS 
>> means).
>
>Actually, they have.  An example given by an internal developer was a
>table with lots of values, where some cells represented data from one
>source, other cells represented data from a different source, etc.
>Based on XHR data, the cells representing a source should all change
>color in a particular way.
>
>Right now the only way to do that is to either (1) loop through the
>elements, setting the .style directly, or (2) use the OM to directly
>tweak the color declaration in the stylesheet.
>
>Neither is optimal.

Term "optimal" when used alone tells us nothing, right?

>From memory consumption point of view 3bit is clearly more optimal
than 33bit. From CPU/memory resources consumption CSS vars (but not CSS 
consts)
are too greedy without doing any good to 99.9(9)% sites and so web users.

One particular problem of particular web developer that can be solved in 5 
lines of
JS code against global warming effects caused by increased and unconditional
memory/CPU demands on each UA connected to the web.
Kind of pathetic of course but ...


And in general size matters indeed if to consider cases like this:
http://terrainformatica.com/forums/topic.php?id=1776

>
>Outside of the direct JS case, parse-time effects outside of the base
>syntax are weird and harder for authors to predict.  Late-loading of
>stylesheets, for example, has difficult-to-predict results if variable
>resolution happens solely at parse time.
>

I've implemented CSS constants year ago or so. And we see no conflicts and
problems you have mentioned since then. Their specification is exactly this:
http://wiki.csswg.org/ideas/constants

Scope of @const declaration is a style sheet where it is declared and
it is seen in all descendant style sheets loaded from it through the 
@import.
So there are no ordering problems that you've mentioned.
At parse time of the loaded style sheet all constants that it can use are 
known
already.

Or I did not get your statement...

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Thursday, 17 February 2011 04:00:19 UTC