W3C home > Mailing lists > Public > www-style@w3.org > May 2012

Re: [css-variables] status ?

From: Marat Tanalin | tanalin.com <mtanalin@yandex.ru>
Date: Sat, 26 May 2012 00:41:20 +0400
To: Tab Atkins Jr. <jackalmage@gmail.com>
Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com>,"www-style@w3.org" <www-style@w3.org>
Message-Id: <6861337978480@web22d.yandex.ru>
25.05.2012, 22:35, "Tab Atkins Jr." <jackalmage@gmail.com>:
> On Fri, May 25, 2012 at 11:16 AM, Marat Tanalin | tanalin.com
> <mtanalin@yandex.ru> wrote:
>> šIt's a shame. Actually _each_ property could be shortened, especially non-shorthand ones, e.g.:
>> šš šbackground-position => $bp
>> šš šfont-family => $ff
>> šš šline-height => $lh
>> šš šword-wrap š => $wr
>> šWhy not just expand CSS variables to use them anywhere?
>> šOr at least not just in property values, but in property names too?
>> šWhat are exact issues with it (if any)?
>> šWhy hardly limit the feature (variables in this case) immediately as fast as it's invented?
> Shortening CSS property names isn't a strong use-case. šNames are
> usually already as short as possible while still being understandable.
> šShortening them further just makes them harder for others to read.

Same applies to using variables in values. There is nothing that really forces us to allow variables in values, but disallow it in property names specifically. This is a weird harmful limitation.

> More importantly, one of the big reasons the CSSWG finally accepted
> Variables is because it offers powers that you *cannot do* with a
> preprocessor. šRewriting property names can totally be done in a
> preprocessor.

Unfortunately using preprocessor is not always possible. Moreover, preprocessor is undesirable intermediate anyway. If some useful feature can be done natively, it should be done natively. We are going to finally (after 15 years) add variables to CSS, but for some reason planning to limit its usefulness willingly.

> You actually *want* the limitations that a preprocessor
> provides here - you *really* don't want a variable you're using for a
> property name to change based on the element's position in the tree.

Why variable as property name should change based on the element's position in the tree? It should be just literally interpolated as string like in preprocessor, but on client side.
Received on Friday, 25 May 2012 20:41:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:16 UTC