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

> > Since my proposals of
> still 
> don't seem to be recognized, I post them here again
> (though some info might already be outdated now):
> [snip proposals]
> None of these are really workable, unfortunately.  They're all
> variants on the older idea of global variables/macros, like what SASS
> currently has.  Current CSS vars are scoped to elements and inherit
> down the element-tree, which adds some decent complexity but also
> opens up some very attractive features.  This isn't replicable with
> anything like the old approach.

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.

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.

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.

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

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.

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.

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

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.


Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro!

Received on Friday, 25 May 2012 05:18:55 UTC