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

>
>
> > Idiomatic usage for variables you want to have globally available would
> > be to put them in a :root { ... } rule.
>
> Yes, that's what I got from the examples.
>
> > This then behaves identically to @-rule approaches, but with the
> > advantage that you can perform value overriding in subtrees should you
> > wish to.
>
> This would also work with @-rules.


Can you explain how?


> > > 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.
>
> It wouldn't necessarily have to be the same abstraction. Though this would
> require somehow typed variables.


I don't see where the need for typed variables comes from. Selector
variables, if they ever existed, could be treated as strings until well
after substitution time.


> > 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?
>
> Well, it was just an example for when a variable could be used for
> selectors. It wouldn't make much sense to put "div" into a variable and use
> that variable inside a selector, no?


I'm pointing out that using variables as selectors is probably almost
always undesirable, because providing this facility encourages the use of
longer selectors, which are a performance issue.


> > > 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.
>
> Then this would comply with suggestion #1.
>

Yes, in this regard they seem to be similar.


> > > 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.
>
> You can't apply variable validation to property types since they are not
> bound to property types. E.g. it isn't possible when you use that variable
> inside a property value like in example 4 and 5.


You can apply variable validation to a variable when it is used within a
given context, and cache the validated value for use when the variable is
again referenced with a similar context. If the context is too complicated
for CSS engine developers to describe succinctly in code, then your
suggestion #2 or #3 will be unable to describe that context in a manner
satisfactory for CSS coders to use.


> > > 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 :)
>
> I didn't propose the golden rule how to implement this. I just showed
> different approaches, which seem to be easier to use than the current ED.


Given the idiomatic usage suggestion above I don't see how this is true -
anyone who wants to use variables like this can do so simply by
substituting some kind of @-block with :root.


> > > 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.
>
> Yes, that's the big difference to the @-rule definition.
>
> > We feel this approach is more consistent with the way everything else
> > in CSS works.
>
> An @-rule would also be consistent with the way everything else in CSS
> works.


I think that @-rules tend to be used in cases where we need to go outside
the core idea of CSS - for example, @keyframes are essentially a way to
describe values for animation-name properties; and exist because these
values are too large to store in a simple string within a CSS rule. The
@keyframes rules are a relaxation of the normal approach of CSS (locally
defined or inherited property values). The @-rule variants of variables
similarly feel like they go outside the core idea of CSS.


> > > 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.
>
> One use case comes to my mind:
> Defining variables for other @-rules like e.g. the @page rule.
>

Why can't the existing approach do this?

Cheers,
    -Shane

Sebastian
> --
> NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!
> Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a
>