- From: Sebastian Zartner <sebastianzartner@gmx.de>
- Date: Thu, 24 May 2012 05:49:49 +0200
- To: "Florian Rivoal" <florianr@opera.com>, www-style@w3.org
> > While I didn't use SASS so far I do not think it will cause such big > > problems. If SASS doesn't adopt CSS variables syntax, it will just > > continue parsing variables in it's own syntax and it's fine. Or it > > will adopt CSS variables and produce less code. The only disadvantage > > for SASS would be one point less on their features list. > > So people using SASS will continue using it and it will work. > > Just to be clear, SASS cannot adopt the CSS variables proposal, as > it depends on the cascade to work and can be interacted with through > the DOM, both of which don't make sense in a server side preprocessor. > They can only be implemented client side, in the browser. > > SASS can keep its own variables as long as we use a syntax that's > different from them, or keep its behavior under a new syntax if > we pick a conflicting syntax for CSS variables, or drop variables > all together. With "adopting CSS variables proposal" I meant SASS would throw away his variables aproach completely in a future version in favor of supporting CSS variables. Because as Jonathan mentioned: > don't make long-term decisions for short-term reasons. > Also note that the $foo syntax won't break any dormant, unsupported > code. > Such code can keep using the old SASS, and producing old-style CSS. The > day I want to upgrade my css output to use $foo variables, I can just > use a translation script to transform all my SASS files, and I'm on to > the new syntax. This just isn't difficult, folks, even if difficulty > for that population mattered. Since my proposals of http://lists.w3.org/Archives/Public/www-style/2012Apr/0814.html still don't seem to be recognized, I post them here again (though some info might already be outdated now): Definition -------------------------------------------------- 1. @variables rule containing variables as properties Example: @variables { header-color: #06c; } Advantages: - All variables can be defined at one place Disadvantages: - No format restrictions for values 2. @var rule for defining one variable as rule Example: @var header-color { background-color: #006; color: #06c; } Advantages: - Properties can be defined like in normal styling rules - Variable can hold several properties Disadvantages: - Overhead when defining several variables - A bit overhead when using variables only for single values 3. @variables rule containing variables as rules Example: @variables { header-color { background-color: #006; color: #06c; } } Advantages: - Properties can be defined like in normal styling rules - Variable can hold several properties - Corresponds to the syntax of other @-rules like @keyframes Disadvantages: - A bit overhead when using variables only for single values Usage -------------------------------------------------- 1. 'var' property Example: h1 { var: header-color; } In case several properties should be allowed in one variable, this could be the syntax. 2. $-syntax Example: h1 { background-color: $header-color; } According to PHP syntax variables could be preceeded by a dollar sign (or another special character that makes it obvious that the value is a variable and not a normal value). 3. var()-syntax Example: h1 { background-color: var(header-color); } The syntax as it's currently suggested. Sebastian -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Received on Thursday, 24 May 2012 03:50:21 UTC