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?

The same way the current WD describes it. The only difference would be that global variables would be defined inside an @-rule instead of a :root-rule.

> > > > 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.

It was you that said that not every possible approach should be forced into the same abstraction.
Yes, I meant to treat variables as strings until they are substituted. So you could reuse them for other things than just property values.

> 
> > > 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.

Allowing to have variables as selectors would not encourage people to write long selectors, they would allow them to tighten up their code.
Giving the example with selectors I just wanted to say that variables should not be limited to property values as some others in this mailing list.

> > 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.

Well, I am not a CSS engine developer, but in the two suggestions I made the validation would already happen where they are defined.

> > > > 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.

You forgot to mention that @-rules like @keyframes or the @counter-style [1] were also introduced to allow reusing them.
Using @-rules for variables would not follow the cascading mechanism like other @-rules. The idea behind that was to have them globally available and just their values would follow the inheriting rules.
Again, the @-rules approach describes global variables while the WD describes an approach that follows the cascading rules.

> > > > 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?

Because the existing approach follows the cascading rules. The @-rule wouldn't. How will you use a variable in different @-rules or in an @-rule and inside the style rules?

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

Received on Saturday, 26 May 2012 19:52:13 UTC