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

Preprocessor variables are, as their name seems to indicate, replaced by 
their value before the CSS engine comes into action. This is a valid use 
case but this is limited to things that are not meant to change. CSS 
variables, on the other hand, are expanded locally, at the time the 
property' value is evaluated. This means that they are kept down the wires 
up to some of the the highest levels of the CSS engine. This is likely to 
have a memory cost that server-side preprocessors aren't subject to.

One difference between a preprocessor-like variable and a CSS one is that 
the values of the CSS ones are not checked to be valid before getting used, 
because variable's type is unknown at declaration time. There's no fallback 
in case the browser don't support the value you used in your variable, it 
won't use another property declaration (because variable is replaced by its 
value after the matching phase). If we want to cover this scenario, we'll 
need to introduce something new, like a fallback function (@supports is a 
good solution, too). For instance, the default value function "var($x, 
value-in-case-of-problem)" is an intended solution to that problem.



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.



However, CSS variables are also meant to serve as a communication channel 
between a document and its components. The easiest way to understand that is 
to remember that, while it's impossible for a language to implement a 
solution for every problem a developer may encounter, it's possible for him 
to provide tools that are generic enough to make it possible to develop the 
solution by yourself.

HTML Components are just that: a way to create your own HTML building 
blocks, like Custom Controls in dotNet or Widgets in Qt. In the document 
markup, you use only one tag (ex: <input type="file" />, <progress>) but you 
define in CSS a list of nodes that going to be created and displayed each 
time such tag is encountered. Those nodes are in the Shadow DOM tree of your 
tag and they are not subject to the styling of your main document.

However, you sometimes need to "give" information to your custom control 
about how it's being used (what colors should it use, which display mode you 
would like...). At this time, no mechanism enables that in CSS. CSS 
variables will allow that. Your custom control' CSS can make use of the CSS 
variables it inherited from its Shadow DOM container to adapt his own 
styling. Scripts running inside those components can also read those 
parameters and use them to tune the way the control will react. With 
cascading CSS variables, you're able to extend the kinds of layout and 
behavior that can be defined and controlled in CSS : for the first time, you 
have the opportunity to extend CSS beyond the written-in-gold styling 
operations. This one of the most important reasons of variable's cascading 
(but I'm sure there are others, maybe Tab has already wrotten a summary 
about that).



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; }

It makes it possible to reduce the complexity of certain selectors, by 
storing certain things in memory. It also provides encapsulation, and we all 
know encapsulation is (most of the time) a good thing.



Beside that, please note I don't say $foo is a BAD syntax for CSS variables. 
In fact, it has several advantages. I would just like to make sure we've 
taken in consideration the fact that it may hides the principles behind CSS 
variables and the reasons of those principles. The CSS WG clearly needs to 
better explain his decision and make sure the syntax it choose don't hurt 
his goals. The choice of syntax is not completely orthogonal to the goals we 
pursue, like it has been debated in the previous weeks.

It seems clear to me (but maybe not to everyone) that to go further we'll 
need, in the future, to allow more and more operations on CSS variables like 
:

    .fileListView::where(x-display-mode: list) {
    }

    .fileListView::where(x-display-mode: grid) {
    }

    .fileListView::where(x-display-mode: thumbnail) {
    }

While I want to make clear this is not going to happen in [css-variables] 
level 1, I think this is where we are heading. But maybe I am wrong on this, 
this is possible.



Okay, now, to crystalize my reasoning: my preference goes to a solution 
where CSS variables look (the most possible) like traditional properties (on 
which some additional operations can be performed because they are not 
directly linked to layout, and are in a more raw state that browser-handled 
properties). I find (but this is a personal opinion) that

    :root { x-foo: value; }
    abcd { property: x-foo; }

serves that "philosophy" better than the $foo syntax does.



This is clearly debatable, but if we debate it, it should not only be from a 
"taste" perspective but also from a "goal" perspective and at the 
"community-comprehension" level.




-----Message d'origine----- 
From: Matthew Wilcox
Sent: Sunday, May 27, 2012 1:49 PM
To: François REMY
Cc: Sebastian Zartner ; Shane Stephens ; jackalmage@gmail.com ; 
www-style@w3.org ; florianr@opera.com ; Sylvain Galineau
Subject: Re: [css-variables] CSS Variables are a NEW kind of variable

Anyone care to explain how these CSS variables are supposed to work,
and give benefits and use-scenarios of them? This is a fine post, but
as one of those people used to PHP/SASS and unfamiliar with how CSS
Variables are different... the post doesn't explain that. So I'm still
clueless as to why $variable as I know and love in SASS is somehow not
right for CSS...

On 27 May 2012 09:26, François REMY <fremycompany_pub@yahoo.fr> wrote:
> The thruth has to be told about "using the $foo syntax for css variables":
> the whole thread clearly show that people are completely failling to see 
> the
> whole point of cascading variables. And if we continue toward that
> direction, people will likely never understand it anytime soon (I speak
> about the usual web developper, not the few ones that read and understand
> the essence of specifications).
>
> 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
>
> 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.
>
> The decision to make the css variables like css properties is what brought
> css variables to life in this working group, what brought so much 
> excitment.
> This idea is really disruptive, this is a bold move and one I truly love.
> However, since we've introduced the idea of the $foo syntax and asked the
> community to show support for it, more and more people are asking to 
> remove
> all that css variables uniqueness (an incredibly useful feature) and just 
> go
> the SASS/Bash way.
>
> The problem is outlined by Stephen Wolfram in a review-of-reviews of his
> latest book :
>
> [...] if people think something is a small idea, they’ll try to understand
> it by straightforwardly extending what they already know. And when that
> doesn’t work, they’ll just be confused. On the other hand, if you
> communicate up front that something is big and important, then people will
> make the effort to understand it on its own terms—and will much more 
> readily
> be able to place and absorb it [...] --
> 
> http://blog.stephenwolfram.com/2012/05/living-a-paradigm-shift-looking-back-on-reactions-to-a-new-kind-of-science/
>
> I'm seriously asking the question: are there any kind of variables 
> existing
> out there who work like the CSS variables? If there's no, maybe it's worth
> stopping to think about what currently exist and try to use a syntax that
> best define the new kind of variable we're trying to define, not a syntax
> that best fit to the currently existing kind of variables.
>

Received on Sunday, 27 May 2012 13:57:39 UTC