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

Re: CSS Variables

From: Jonas Hartmann <j0n4s.h4rtm4nn@googlemail.com>
Date: Sun, 6 Feb 2011 12:24:47 +0100
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Message-Id: <F76A4F55-3E34-4C13-A5D1-0513BBAF08AF@googlemail.com>
To: David Woolley <forums@david-woolley.me.uk>
Hello,

On 2011-02-06, at 11:55, David Woolley wrote:

> Tab Atkins Jr. wrote:
> 
>> never agree on how it was supposed to work.  This sucks for authors,
>> particularly as the rise of preprocessing frameworks like SASS have
>> shown just how popular and useful variables are in designing and
>> theming webpages and webapps, both large and small.  I and some other
> 
> The fact that this can be done by pre-processors is actually a counter-argument to including it in CSS.

The pro arguments are:
- preprocessors are not documents but applications. You cannot "simply" put them on an USB stick or transfer them from one server any other server.
- css code size is reduced dramatically by modules/mix-ins (not so much variables imho). This "benefit" vanishes after SASS/LASS/LESS compiles things.
-> Client side modules/mix-ins and variables can reduce code size (less traffic) and improve maintainability (less cost) by a huge factor.

So why is it a counter argument for(against?) including into CSS just because it "can" be done by pre-processors?

The counter argument I see is backwards compatbility. CSS always or mostly rendered fine on older clients. That means a property is either evaluated or ignored. If a property is known but the variable feature is not, what happens then? How do real world clients interpret that?
Received on Sunday, 6 February 2011 11:25:25 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:37 GMT