Re: [css-variables] CSS Variables are a NEW kind of variable

> To summarize, we have :
> - people asking to be able to use $foo anywhere (even in selectors,
> property names)
> - people asking to not have to use :root for setting variables and 
> asking for @variables instead

Obviously this refers to my mails earlier in the other related threads.
While I first was very distracted about how you imagine CSS variables to work I'm now starting to understand the reasons behind the chosen way they shall work.
Though I still see some restrictions to the currently specified syntax.

> It's important to understand that CSS variables are inherited from the
> parents and are able to emulate some preprocessor-like variables: one
> variable can be defined at one place, the root of the document, and stay
> unoverriden everywhere else. The main use-cases of such globals are to 
> allow alternate stylesheets to redefine constants instead of redefining 
> a whole set of css declaration, and to promote the use of easily 
> maintainable css code. Both are pretty important use cases.

As I understand the current model and pointed out earlier the current concept is limited to the element tree. People won't be able to put something into a variable that is not inside of it, i.e. @-rules defining font faces, counter styles, page styles etc.
Please let me know if I am wrong in this point.

> In fact, this is even working for non-custom controls :
> 
>     footer a { color: red; }
>     header a { color: green; }
>     article a { color: blue; }
> 
> can be rewritten into the more efficient (there's no composite 
> selector) :
> 
>     a { color: $link-color; }
>     footer { $link-color: red; }
>     header { $link-color: green; }
>     article { $link-color: blue; }

I am not a CSS engine developer, but this looks more inefficient to me from both views, a web developer's one and from an engine developer's perspective.
As web developer you have to write more while you would expect to be able to shorten your CSS using variables. Also you have to keep the element tree in mind and the order in which you defined your variables.
As engine developer you will have to tell the engine to save a reference between the selector using the variable, walk up the tree and check if the parent elements include a value for the saved variable. So in the given example instead of just having to check for "a" being somewhere inside of "footer" you'll additionally have to check if they contain the variable.

> People are excited to reuse, for css variables, a syntax used in many
> programming and templating languages to do preprocessor work (echo "xxx
> $foo xxx" in PHP, dir $folder in Bash, ...) because this is what they 
> expect from CSS variables. They expect them to do preprocessor work. 
> Have you seen a voice outside this working group asking publicly for 
> cascading variables?
> No, because most people haven't heard of that, and aren't likely to
> understand its implications. We're developing CSS variables in 
> expectation of HTML Components, Shadow DOM and many things people are 
> not yet understanding, because they simply don't exist at this time.

That's not completely true. Mozilla already offers some kind of shadow DOM and creating own components for many years via XBL.
Inventing something new is also always dependent on people's acceptance. So you could fail with this idea of CSS variables just because people don't understand their usage or are not willing to use them, even when the concept seems very promising.

Also I am wondering why the working group refuses to implement a simple (preprocessor) solution first (which would already make most of the people happy) and later enhance it by the cascading solution.

Anyway, I'll excitedly continue following this development and hope that in the end we'll have a solution people are happy with.

Sebastian
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Received on Monday, 28 May 2012 22:42:01 UTC