Re: CSS Variables Draft Proposal

On Tue, Feb 15, 2011 at 8:07 AM, Christoph Päper
<christoph.paeper@crissov.de> wrote:
> Tab Atkins Jr.:
>> <http://www.xanthir.com/blog/b4AD0>.
>
> Sometimes variables have been requested to work inside selectors and even properties, too. I think it’s a good thing this proposal does support only values (and sub-values).

I may eventually want to talk about selector variables, but they don't
start being justifiable until you get both Mixins and Selector
Nesting, neither of which have been introduced yet.  Even then I'm
having trouble convincing my team they'd be useful.


> That being said, custom units as in “font-size: 12$dd” (for the Didot point) could be useful, but are certainly not the most convincing nor common use case.

@var $didot-point 1.065pt; /* I'm guessing at the value here */
p {
  font-size: calc( 12 * $didot-point );
}


>> Variable Syntax
>>
>> The syntax for variables is very simple.  Variables are defined in an
>> `@var` rule anywhere in the sheet
>
> How much are you decided on using the abbreviation “var”?
> Possible alternatives:
>
>  – @let
>  – @set
>  – @new
>  – @value
>  – @macro
>  – @define
>  – @declare
>  – @keyword
>  – @constant
>  – @variable
>  – …
>
> How about an (optional) equals sign or colon after the name?
>
> A little verbosity sometimes does wonders to usability and CSS tends to avoid abbreviations, except in form of acronyms (as in ‘url’ and ‘rgb’ for instance).

I'm looking for short and sweet, and easy to use in other contexts.
Javascript already uses "var" as the word for declaring a variable,
and it's easy to talk about "CSS Vars" and know that we're talking
about @var.


>> Multiple Variable Declarations
>>
>> If the same variable name is declared in multiple @var rules, the last
>> valid declaration wins.  For this purpose, UA-defined variables come
>> before all author-defined rules, which come before all user-defined
>> rules.  Within each category, the ordering is document order.
>
> I am against making variables available across sources (i.e. the trinity of user agent, author and user), except perhaps when explicitly requested to, like this:
>
>  @var $foo bar !important;
> or
>  @var $foo bar !override;
>
> That, of course, would require to end the variable content when encountering an exclamation mark, i.e.
>
>  @var $foo bar !important;
>  baz {quuz: $foo}
>
> would be different from
>
>  baz {quuz: bar !important}

That seems like an odd distinction to make.  Most people, if they want
to limit the scope of variables, try to limit them to the defining
sheet and possibly imported/importing sheets.

In any case, I agree with Daniel here.  This seems confusing, and I
don't see the benefit of restricting variables in this way.

~TJ

Received on Tuesday, 15 February 2011 18:37:11 UTC