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

> > Disadvantages:
> > 1. Variable's availability depends on element tree:
> > See example 6:
> > <one><two><three /></two></one>
> > one   { var-foo: 10px; }
> > two   { var-bar: calc(var(foo) + 10px); }
> > three { var-foo: calc(var(bar) + 10px); }
> >
> > The variable "foo" is assigned another value inside <three>. If the
> > order of <one>, <two>, <three> is reversed or <two> is used without 
> > being inside a <one> element, the "foo" variable is rendered invalid 
> > for it.
> > So while properties inside that rules will always be assigned to the
> > element variables always depend on where the matched element is placed
> > inside the tree, which can be quite confusing.
> > With an @-rule approach you wouldn't have this problem because 
> > variables would always be accessible. They would just be scoped by 
> > @media rules.
> 
> 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.

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

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

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

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

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

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

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

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

Received on Friday, 25 May 2012 06:48:30 UTC