- From: Jon Rimmer <jon.rimmer@gmail.com>
- Date: Sun, 6 Feb 2011 15:51:00 +0000
- 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. Thanks, Jon
Received on Sunday, 6 February 2011 15:51:32 UTC