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

Re: CSS Variables

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 7 Feb 2011 10:59:59 -0800
Message-ID: <AANLkTimxBHjGjH7xtx51Ryz9mBeHHXdD7Y9xLkPsjqcF@mail.gmail.com>
To: David Woolley <forums@david-woolley.me.uk>
Cc: www-style list <www-style@w3.org>
On Sun, Feb 6, 2011 at 5:03 AM, David Woolley
<forums@david-woolley.me.uk> wrote:
> Jonas Hartmann wrote:
>> So why is it a counter argument for(against?) including into CSS just
>> because it "can" be done by pre-processors?
> It avoids including things in the over-the-wire protocol specification that
> are not needed for correct rendering.  That means one less thing that
> browsers have to get exactly right for interoperability.

Indeed, one must always weigh the benefits against the cost of
achieving interop.  Syntax improvements have real benefits, though.  I
believe that CSS preprocessor frameworks have shown that people gain a
lot of benefit from the brevity and centralization that variables (and
other things like mixins) can bring to large sites and applications.

>> The counter argument I see is backwards compatbility. CSS always or
> In particular, remember that some clients can be frozen a decade ago. This
> is especially the case if they are used by people outside the pop culture
> generation.

Those clients don't understand modern CSS 2.1, let alone new CSS
stuff.  We shouldn't make decisions about what to change based on
frozen clients that won't change.

(Using ancient clients is bad for *many* reasons, of which outdated
feature support is only one of them - they're generally *much* more
vulnerable to viruses and exploits, for example.)

Received on Monday, 7 February 2011 19:00:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:56 UTC