W3C home > Mailing lists > Public > www-style@w3.org > February 2011

Re: [css-variables] Hidden costs.

From: Andrew Fedoniouk <andrew.fedoniouk@live.com>
Date: Wed, 16 Feb 2011 19:59:45 -0800
Message-ID: <BLU159-ds11CED9048DB185B0FC3C2FF8D50@phx.gbl>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: <www-style@w3.org>
>-----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 
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:

>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:

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 
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 

Or I did not get your statement...

Andrew Fedoniouk

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

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:34:48 UTC