

A Vote for CSS Variables - scoregoals12
http://www.piehead.com/blog/2012/03/a-vote-for-css-variables

======
lucian1900
CSS constants! Names, symbols, whatever. Just don't call them something that
implies they change all the time.

~~~
richthegeek
If they act in a similar way to variables in SASS, then they can be reassigned
without issue. They are not constant, although they may be treated as such.

Of course, the CSSWG will no doubt create a solution that is both absurd in
it's complexity, and limited in it's use. For example, constants defined with
css-constant('foo', 'bar') instead of $foo: bar

~~~
masklinn
> For example, constants defined with css-constant('foo', 'bar') instead of
> $foo: bar

The issue with sigil is that they risk conflicting with (and making more
complex the parsing of) selectors. `$` used to be coopted by the Selectors
Level 4 draft spec in order to select a non-tail subject for instance (it's
apparently been changed to the `!` suffix).

Not that I like what they picked any more than you do (the spec is currently
using the `data-` prefix for definition and `data()` for dereference, likely
in keeping with HTML5's `data-` attributes)

------
MatthewPhillips
I'm really afraid of CSS having too much logic and driving designers away. I
don't want to go back to the days when designers mocked up in Photoshop and
had devs (inferior designers) do the CSS.

~~~
tripzilch
The mythical designer that

1) is able to write valid cross-browser CSS ready for deployment without
developer tweaking

2) would not understand basic logical constructs such as CSS Constants.

does not, in fact, exist. At least, I have _never_ met one.

Think of it like this, imagine there is a sort of spectrum for capability of
abstract logical/mathematical related thought. Roughly, on one extreme end
there's someone who is so intuitive practical you wouldn't trust to properly
split a dinner bill (this is not a "designer stereotype" btw, but an example
of the very extreme end of the scale), in between there's doing calculations,
solving simple equations, writing CSS, writing CSS-with-constants, using a
templating language, doing actual coding, hardcore coding genius, and at the
far end there's Neo who can stop bullets with his mind by wearing the right
kind of shades and longcoat.

Your fear of "having too much logic and driving designers away" is _only_
valid if the _majority_ of web-designers fall right between "capable of
writing CSS" and "capable of writing CSS with constants". Sorry but that's a
rather narrow range and I'm not buying it.

And the few designers that happen to fall exactly in that range will either
have to write CSS without constants (which is fine), or learn to deal with it.

~~~
MatthewPhillips
I'm not saying that this is the spec that pushes CSS into the code-territory.
I'm not saying there is any one spec that does. I'm looking at the aggregate
of CSS4 and am afraid that we are _heading in that direction_. See, for
example, the crazy (and awesome, btw) things you can do in upcoming selectors
such as matches[1] combined with a for[2], or the mind-bender that is the
shadow dom[3].

[1] <http://dev.w3.org/csswg/selectors4/#matches> [2]
<http://dev.w3.org/csswg/selectors4/#idref-combinators> [3]
[https://dvcs.w3.org/hg/webcomponents/raw-
file/tip/spec/shado...](https://dvcs.w3.org/hg/webcomponents/raw-
file/tip/spec/shadow/index.html)

~~~
debacle
I think the more important reality is that TIMTOWTDI doesn't really belong in
CSS, and that's what we're seeing happen more and more.

Part of the problem is that CSS And rich internet applications can't really
properly coexist - they do now, because that's part of how we work, but as
time goes on the amount of lifting we're going to want to do with JavaScript
is only going to continue to increase.

------
mmatants
I think future Web standards should take out the Gecko/Chrome/IE
layout+parsing engine and make it a separate library. Standardize a
minimalistic (but powerful) GL-style presentation API.

Why are standards committees dictating developer workflow? We should be able
to swap in our own parser and UI framework (which is what DOM is) that fits
the specific website/webapp needs best. Not reinventing the wheel, of course -
things would naturally coalesce into ubiquitous standard libraries, but a bit
more competitively.

~~~
sixcorners
Then maybe we can get rid of all this javascript stuff and start sending .exe
files to each other.

------
twfarland
This wouldn't make css any more powerful than it can be when treated as a
compilation target. You can get all the logic you need in a preprocessor
embedded in another language, e.g for js I made this:
<http://github.com/twfarland/son>

New styling possibilities would be more interesting, e.g layer blend modes.

------
xutopia
The issue is speed. CSS has to be fast if we want to display pages quickly. An
alternative I prefer is lesscss.org or sass-lang.com.

~~~
woogychuck
I really don't see how this would have a major negative impact on speed. If
anything, it will allow CSS files to be smaller reducing the amount of data
being downloaded to the client and may actually improve performance.

------
mattmanser
I hadn't seen that spec before. That really is one truly awful spec on so many
levels.

<http://dev.w3.org/csswg/css-variables/>

~~~
TylerE
It's W3C, what were you expecting? It's the very best example of death-by-
committee I've ever seen. If they designed a lightbulb, it'd require a 9 step
checklist just to get it out of the packaging, wouldn't fit in the industry-
standard socket (because, of course, they've reinvented the wheel again,
poorly), and by the time you actually got the thing installed the rest of the
world will have moved on to better light-producing devices, but will be forced
to deal with the W3C brain-damaged version of the lightbulb because it's a
"standard".

