
CSS Variables in Firefox 29 - reimersjan
http://jan.rs/blog/2014/05/03/css-variables-firefox-29/
======
heycam
Please note that the final syntax for CSS Variables changed recently, so in
Firefox 31 and later, where the feature is enabled by default, you declare
variables like this:

:root { --spacing: 16px; }

and reference them like this:

body { padding: var(--spacing); }

~~~
kijin
Who comes up with these weird syntaxes? First it was var-foo, now it's --foo.
What's next, \foo?

"\--" is almost universally used as a decrementing operator, and it's also a
common prefix for verbose shell options. Just because you're now working with
a different language doesn't mean that you are free to repurpose other
languages' operators for entirely unrelated purposes. It's just a recipe for
confusion, not to mention it's ugly.

I thought I'd seen the worst when PHP picked backslash as the namespace
separator. Now it's just getting crazy. Why couldn't they just pick a normal
sigil that everyone already understands, like the dollar sign?

~~~
heycam
As pornel pointed out, CSS Variables are really custom properties that cascade
and inherit just like regular properties. Since "$" is used by CSS
preprocessors for variables that work in a different way, I think Tab felt
that it would cause too much confusion to use the same symbol. The set of
remaining ASCII non-alphabetic characters that CSS doesn't use is pretty small
too; perhaps "$" is slated for use by some other feature.

There's also a desire in the WG to have a consistent naming scheme for custom
CSS things, including custom media queries, custom pseudo-classes to use in
selectors, etc. "\--" is something that doesn't scream "variables" and so
would be usable for those other things.

~~~
parallelist
> Since "$" is used by CSS preprocessors for variables that work in a
> different way

A complete perversion of priorities. CSS generator languages change and go in
and out of fashion all the time but CSS itself will be around for a very long
time. They should make the best decision for the future of CSS. Generator
languages are inevitably going to need to change to take advantage of any new
feature anyway.

~~~
kijin
I agree. The people who develop web standards nowadays seem to have a curious
aversion to existing implementations. First they rejected WebSQL because it
was based on SQLite. And now they can't use the dollar sign because it's used
in Sass? Is this just a bad case of NIH syndrome, or is there something more?

------
neals
I wasn't paying attention the last time we had some awesome additions to CSS.
How does something like this get adapted?

Do developers actually only use this on FF29+ until all browser adapt? Is this
one of those things where we will see workarounds for older browser for
decades to come?

Or is this more something that CSS frameworks like LESS pick up and the actual
thing is abstracted away for a couple of years still?

This does seem like a very useful feature.

~~~
thefreeman
The good news is that at least now a large majority of users are on browsers
with auto update. So once the spec is finalized and browsers start to enable
it by default you should get a pretty large % of users who will support it.

You will likely have to have a separate stylesheet for older versions of IE
(and possibly other browsers) but honestly you likely have that anyway. And
it's a lot easier to update a few values in that then throughout your entire
site.

We'll see how it plays out but I certainly wouldn't expect to use them in
production for quite a while yet. I'm sure that is why they hid it behind an
about:config option for now.

------
snird
Here is the pen with the updated syntax for CSS variables, for those who run
Firefox aurora (31) where it is updated and enabled by default:
[http://codepen.io/snirda/pen/vnDkb](http://codepen.io/snirda/pen/vnDkb)

------
nperson
It used to be possible to enable CSS variables support via chrome://flags'
#enable-experimental-web-platform-features in previous Chrome builds. Support
has since gone again. Hoping for a reappearance soon.

CSS Variables in combination with an additional build step[1] is actually
quite usable right now.

[1] [https://github.com/segmentio/myth](https://github.com/segmentio/myth)

Edit: The introduction of the new notation as mentioned by heycam, explains
Chrome's behavior a bit.

------
userbinator
After looking at the spec, I'm wondering does this really save anything for
the client, vs. doing this in a CSS preprocessor? Instead of spending the time
compiling once and then having clients interpret declarations, _every single
user who visits the site_ will have their browser perform the same
computation, _every time they visit a page that uses these_. It's also another
source of significant complexity to the browser.

~~~
pornel
CSS Variables are a misnomer. They're _custom properties_ that obey cascade
and inheritance.

CSS preprocessors can do only lexically scoped substitutions. With CSS
"variables" you can have values inherited within DOM's scope.

~~~
ufo
Can you give an example of a situation where you would rather have cascading
variables than lexical scope?

~~~
pornel
• JS libraries implementing polyfills for new CSS properties or their own CSS-
like behaviors (e.g. `--masonry-display: jagged-grid`)

• themes (`--theme-color` that can be inherited and overridden just like
`color` would)

------
benschwarz
Chrome / Blink has pulled the implementation for now because of changes to the
spec / poor implementation. It'll come back (in time).

Ref to feature being removed:
[https://groups.google.com/a/chromium.org/forum/#!topic/blink...](https://groups.google.com/a/chromium.org/forum/#!topic/blink-
dev/ScKw9zYRkBc)

Right now, Firefox 29, Aurora and Nightly are the only browsers that have CSS
Variables shipped. (Although, there is still no CSSOM implementation present —
that'll come later.)

------
transfire
What a sad joke. Maybe one day the W3C will get a clue and do this:
[http://gridstylesheets.org/](http://gridstylesheets.org/). But I won't be
holding my breath.

~~~
err4nt
Not having constraint-based algorithms isn't what's holding CSS back, if we
used @media queries on the widths of elements themselves instead of browser
dimensions we could implement really REALLY advanced layouts with the CSS we
already have.

I wish I could do CSS like this:

.container .headline { font-size: 14pt; }

@media .container (min-width > 500px) {

    
    
      .headline {
        font-size: 18pt;
      }
    

}

@media .container (min-width > 900px) {

    
    
      .headline {
        font-size: 24pt;
      }
    

}

I don't really care how wide the browser itself is. I don't care how big the
device is or the orientation. If I know in the layout this element is going to
be squished below 300px at some point,easily let me make styles for when that
ELEMENT is below 300px and I can build layouts that will look pixel-perfect at
any size on any screen

No GSS or constraint-based languages necessary

~~~
joaren
So how do you make it so that text always sizes to fit its container,
vertically and horizontally? i.e. Sliding font size and letter spacing. Pixel
perfect on any screen?

~~~
err4nt
To be honest, here's how I tackled that very problem last week using
JavaScript to supercharge my CSS.

Here's the layout challenge: There's an account settings page with a Page
title, underneath that there's the user's avatar, name, and team name, and
then below that we have a number of settings tabs sorted by function (general,
notifications, social, funding, etc.)

I wanted the avatar + names to remain center-aligned at all times, and I need
this layout to work from 320px up to 1200px. What do I do? Usernames are 3
characters minimum, and 20 characters maximum. That's quite a range.

So, I wrapped the Avatar and Names inside a container. Used JavaScipt to
measure the container, at at page load (and any time the browser is resized)
it does something like this:

.avatarContainer { position: absolute; top: 0; left: 50%; margin-left: (minus
half of the current width of .avatarContainer); }

Woo, okay, so now no matter how long the name is, that avatar and name will
stay visually centered. So my next challenge is to find three font-sizes (as
we do phone, tablet, and desktop breakpoints) that will display the name large
enough that it's legible with a three-letter name, but that can still fit a
20-letter name without cutting it off.

Second challenge: Automatically resize the text to 'squish' it, if the number
of characters is greater than 15. So at any of my breakpoints JavaScript will
also watch the element that holds the username, and if at any point that count
goes higher, the font-size decreases to squish it all in.

Add the two together and you've got a resilient layout that looks perfect at
any size between 320px and 1200px wide, even as the user changes the
dimensions of the browser or the content on the page after it has loaded.

I wish I could have done that 100% in CSS but CSS makes you DECLARE things,
which presupposed that you can anticipate their exact dimensions. I want to
use the full power of CSS for layout after the page has loaded as the content
adapts, so I needed a more clever way to define more styles and the cases
during which they apply than CSS @media queries allowed.

If what I'm saying is intruiguing, check out my experiments in using
JavaScript to boost CSS here, maybe even suggest a few things!
[https://github.com/tomhodgins/alijn](https://github.com/tomhodgins/alijn) and
[http://staticresource.com/alijn/demo](http://staticresource.com/alijn/demo)

~~~
joaren
No, what you're saying is the opposite of intriguing. It was exactly what I
expected: an admission that CSS is insufficient for "really advanced layouts"
without JavaScript.

------
kanu
Cool Jan :)

