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

Re: RE: [css-variables] Using $foo as the syntax for variables

From: Shane Stephens <shans@google.com>
Date: Fri, 25 May 2012 15:35:34 +1000
Message-ID: <CAGTfzwR9KczoFa7Wt62ADK-jq7wOF--vPn+HMUOdX4FJm-3=Bw@mail.gmail.com>
To: Sebastian Zartner <sebastianzartner@gmx.de>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style@w3.org, florianr@opera.com
> Sorry, I missed the earlier discussions about CSS variables. Could you
> explain which "very attractive features" that would be? Currently I just
> see the decent complexity this approach has.
> Approaches using an @-rule would not allow to define a variable to be
> valid inside a specific element subtree but the variable values would still
> be inherited down the element tree. And their usage is a lot easier than
> the var- declaration inside style rules.

I'll let Tab answer this more fully, but one advantage is laid out in my
response to your point #1.

> Disadvantages:
> 1. Variable's availability depends on element tree:
> See example 6:
> <one><two><three /></two></one>
> one   { var-foo: 10px; }
> two   { var-bar: calc(var(foo) + 10px); }
> three { var-foo: calc(var(bar) + 10px); }
> The variable "foo" is assigned another value inside <three>. If the order
> of <one>, <two>, <three> is reversed or <two> is used without being inside
> a <one> element, the "foo" variable is rendered invalid for it.
> So while properties inside that rules will always be assigned to the
> element variables always depend on where the matched element is placed
> inside the tree, which can be quite confusing.
> With an @-rule approach you wouldn't have this problem because variables
> would always be accessible. They would just be scoped by @media rules.

Idiomatic usage for variables you want to have globally available would be
to put them in a :root { ... } rule. This then behaves identically to
@-rule approaches, but with the advantage that you can perform value
overriding in subtrees should you wish to.

> 2. Can't be used for anything else than property values [1]:
> Within an @-rule you could define all this, which helps for example when
> you have a very long selector. You will just put that selector into a
> variable and can then use it at any place you wish.

Long-term, I am quite keen at looking at other abstractions for re-use and
modularity in CSS, but I am not keen to try and force every possible
approach into the same abstraction. Selector fragments have different
properties to value variables, and should be addressed separately, even if
we end up using similar syntax in the long run.

Additionally, it's not actually clear to me that you really want to have
very long selectors, given the performance problems that you'd incur.
Should we be encouraging this sort of thing?

> 3. Variable values are not bound to any type of property:
> Example 8:
> :root { var-looks-valid: 20px; }
> p { background-color: var(looks-valid); }

Yes. This is an advantage. CSS doesn't have types, except at property
application time. We don't want to force a new type abstraction on CSS
developers just so they can use variables.

Remember that
p { background-color: 20px; }

is perfectly well handled by today's CSS engines.

> Example 9:
> :root { var-not-a-color: 20px; }
> p { background-color: red; }
> p { background-color: var(not-a-color); }
> My suggestions #2 and #3 bind a value to a specific property type, so a
> variable validation can already take place inside the @-rule and doesn't
> have to be done everytime the variable is used.

I'm not sure what you're getting at here. Variable validation to a
particular property type is quite cacheable.

> Admittedly allowing to define a variable value independently of a property
> is also an advantage since you can define e.g. a color value and use it in
> different properties. See my suggestion #1.

Indeed. Calling out late-validation as an issue in the current WD while
proposing it at the same time is an interesting move :)

> After all variables are something that doesn't affect the elements
> directly. So also logically they fit more into an @-rule.

I guess this is the core point at which the CSSWG feels differently. From
our perspective, variables are properties without direct effect on layout
or rendering. Properties get set on elements and inherited down the DOM, so
variables should too. We feel this approach is more consistent with the way
everything else in CSS works.

> Anyway, an @-rule defines a global variable definition while the current
> ED describes scoped variables. So both approaches do not exclude each
> other. So maybe both could find their place inside the spec.

Given the attitude of the CSSWG towards variables defined at global scope
in the past, this isn't likely. It is certainly possible, however, should
you find any important use cases for variables in @-rules that can't be
solved simply by using the :root selector.


> [1] http://dev.w3.org/csswg/css-variables/#using-variables
> [2] http://dev.w3.org/csswg/css-variables/#defining-variables
> [3] http://lists.w3.org/Archives/Public/www-style/2012Apr/0814.html
> Sebastian
> --
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Received on Friday, 25 May 2012 05:36:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:59 UTC