CSS Variables in Firefox 29(jan.rs)
jan.rs
CSS Variables in Firefox 29
http://jan.rs/blog/2014/05/03/css-variables-firefox-29/
8 comments
thanks for the hint. i will update my demo asap
I think this is the latest version, and it does show "--" syntax - it's still a work in progress though: http://dev.w3.org/csswg/css-variables/
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?
"--" 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?
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.
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.
> 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.
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.
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?
I agree, that is terrible. In html we already have comments with <!-- -->
-- is also the inline comment syntax for various programming languages (http://en.wikipedia.org/wiki/Comparison_of_programming_langu...)
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.
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.
According to caniuse, the global support for variables is 0.01% right now. http://caniuse.com/#search=variables
I think it will take some time until there is enough browser support to use variables on a productive site. but maybe browsers will implement this faster... there's hope
I think it will take some time until there is enough browser support to use variables on a productive site. but maybe browsers will implement this faster... there's hope
LESS and co. can't implement this, because CSS variables are cascading.
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.
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.
No, people will carry on using SASS until support for this feature is well and truly widespread.
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
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
Edit: The introduction of the new notation as mentioned by heycam, explains Chrome's behavior a bit.
CSS Variables in combination with an additional build step[1] is actually quite usable right now.
[1] https://github.com/segmentio/myth
Edit: The introduction of the new notation as mentioned by heycam, explains Chrome's behavior a bit.
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.
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.
CSS preprocessors can do only lexically scoped substitutions. With CSS "variables" you can have values inherited within DOM's scope.
Can you give an example of a situation where you would rather have cascading variables than lexical scope?
• 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)
• themes (`--theme-color` that can be inherited and overridden just like `color` would)
Less dependency on third party tooling.
Many companies are weary of extra dependencies on their developer tooling.
Many companies are weary of extra dependencies on their developer tooling.
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...
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.)
Ref to feature being removed: https://groups.google.com/a/chromium.org/forum/#!topic/blink...
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.)
What a sad joke. Maybe one day the W3C will get a clue and do this: http://gridstylesheets.org/. But I won't be holding my breath.
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) {
@media .container (min-width > 900px) {
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
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
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?
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 and http://staticresource.com/alijn/demo
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 and http://staticresource.com/alijn/demo
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.
Cool Jan :)
:root { --spacing: 16px; }
and reference them like this:
body { padding: var(--spacing); }