- 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