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

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

From: Sebastian Zartner <sebastianzartner@gmx.de>
Date: Thu, 24 May 2012 05:49:49 +0200
Message-ID: <20120524034949.261740@gmx.net>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:54 GMT