- From: Jonas Hartmann <j0n4s.h4rtm4nn@googlemail.com>
- Date: Sun, 6 Feb 2011 12:24:47 +0100
- To: David Woolley <forums@david-woolley.me.uk>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
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 UTC