- From: Shane Stephens <shans@google.com>
- Date: Fri, 25 May 2012 15:35:34 +1000
- To: Sebastian Zartner <sebastianzartner@gmx.de>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style@w3.org, florianr@opera.com
- Message-ID: <CAGTfzwR9KczoFa7Wt62ADK-jq7wOF--vPn+HMUOdX4FJm-3=Bw@mail.gmail.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. Cheers, -Shane > > [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