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

Re: CSS Variables

From: Jon Rimmer <jon.rimmer@gmail.com>
Date: Sun, 6 Feb 2011 15:51:00 +0000
Message-ID: <AANLkTinum9Hg3+ro+hTVbmJUXah8Kxo=BvhiuvXsx59O@mail.gmail.com>
To: David Woolley <forums@david-woolley.me.uk>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
On 6 February 2011 10:55, David Woolley wrote:
> The fact that this can be done by pre-processors is actually a
> counter-argument to including it in CSS.

The existence of pre-processors should not preclude the adoption of
new features into CSS. If anything, they should be taken as an
indication of where the language is not meeting the needs of authors
and requires improvement. A comparable example is CoffeeScript, a
scripting language that compiles into JavaScript, the features of
which are informing the future of the ECMAScript standard. The task of
those responsible for evolving any technology is to judge which
enhancements are worth pursuing by weighing their costs in terms of
complexity, implementation burden, and backwards-incompatibility,
against the benefits they provide and their expected popularity.

In the case of CSS variables, pre-processors are useful, but not
everything can be done with them. A subset of it can be, but since the
variables are not reified in the CSSOM, it's impossible to access and
modify variables in the browser. I suppose you could have a
client-side script to parse the custom language, produce CSS, and also
maintain its own corresponding object model to allow later changes,
but such a complex, Russian-doll style approach hardly seems desirable
just to avoid making additions to CSS itself.

Received on Sunday, 6 February 2011 15:51:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:43 UTC