I like it. The syntax actually feels more css-like to me than what most preprocessors use. But never mind the syntax, the killer feature us the cascading - that's what sells me on this vs SASS/LESS/etc. (And, having it native is also nice - this way I can just dump something on Github Pages and skip the compilation step.)
CSS Variables in Firefox 31 – new syntax
41–50 of 54 posts
Re: CSS Variables in Firefox 31 – new syntax
#42Why do you have to use var(--name) when the parser already knows it's a variable from the -- prefix? Surely property: --name; is nicer than property: var(--name); ?
Re: CSS Variables in Firefox 31 – new syntax
#43Does the W3C not have internet access to learn about existing solutions and least try to emulate the good parts? LESS and SASS are much better about variables, what the heck were they thinking? background-color: var(--best-gray-ever); Not exactly intuitive or easy to parse at a glance.
> what the heck were they thinking?
I don't know, maybe about how to design a spec that is compatible with past and future CSS parsers and features?
People think it's so simple to come up with a new feature for CSS/HTML/JS, when actually, they have no idea how difficult it is.
They're smarter than that: http://www.xanthir.com/blog/b4KT0
Re: CSS Variables in Firefox 31 – new syntax
#44Does the W3C not have internet access to learn about existing solutions and least try to emulate the good parts? LESS and SASS are much better about variables, what the heck were they thinking? background-color: var(--best-gray-ever); Not exactly intuitive or easy to parse at a glance.
> what the heck were they thinking? I don't know, maybe about how to design a spec that is compatible with past and future CSS parsers and features? People think it's so simple to come up with a new feature for CSS/HTML/JS, when actually, they have no idea how difficult it is. They're smarter than that: http://www.xanthir.com/blog/b4KT0
Sure,but when the spec is bad at first place,no new feature can be good.So hell yeah ...
> what the heck were they thinking?
...At first place when they wrote CSS.
CSS is a disaster,and one of the worst spec ever written in my book.
> People think it's so simple to come up with a new feature for CSS/HTML/JS, when actually, they have no idea how difficult it is.
Aside from HTML,CSS and JS are "defacto" standards since vendors werent able to agree on a better spec when they should have. only developpers can fix these with tools they build.Devs cant rely on these technologies on their own.That's why they have CSS and JS preprocessors.Because while it's crap at the end of the day devs need to build on top of that crap.
Re: CSS Variables in Firefox 31 – new syntax
#45Earlier quoted context omitted.
And does your styling work in a webbrowser where JS is disabled?
Not trolling, I really don't understand: why would you disable JS when browsing the web?
Not wanting to execute arbitrary untrusted code on your machine? While there has been lots of good work put into sandboxing browser by the browser vendors, the ability for attackers to run custom code within the browser makes many exploitable vulnerabilities a lot easier to exploit. Things like the various privacy leaks based on cache timing, visited link styles, and so on, or just exploiting buffer overruns that have been protected against by address space layout randomization but with arbitrary code the exploit can try the same thing over and over again with different size inputs until it finds one that works.
Running JavaScript in your browser automatically from any site that you visit is pretty darn scary when you think about it. You can protect from a whole host of vulnerabilities by disabling it, and then whitelisting only hosts which you trust.
Re: CSS Variables in Firefox 31 – new syntax
#46Earlier quoted context omitted.
Yeah, obviously they need to avoid conflicts but surely they could have found a single character to use as a prefix instead of "--", like "$" or "@". The "var()" function is just.. redundant. Or maybe I'm missing something?
Here's the discussion where they changed from "var-" to "--": http://lists.w3.org/Archives/Public/www-style/2014Mar/0261.h... And later on the justification for not using $ or @: http://lists.w3.org/Archives/Public/www-style/2014Mar/0400.h... There's also the issue that this needs to be backwards compatible with parsers that don't support the syntax, and apparently because the variables cascade that makes it harder s…
Variable is a BIG change in CSS. If a browser doesn't support variable, then new stylesheets are already broken in that browser. It makes little difference to make the syntax compatible.
Once an easy-to-use syntax is published, toolchains that parse CSS will update as fast as they can! But "--"? Everybody will stick to the old standard and never want to upgrade.
Re: CSS Variables in Firefox 31 – new syntax
#47Does anyone know if the var() function only work with the variables? For example, can I do something like: background-color: var(color);?
In case you didn't know, there's already a special version of the `inherit` keyword for using the color value in other properties:
background-color: currentColor;
Re: CSS Variables in Firefox 31 – new syntax
#48Can anyone think of a use case for this beyond what a precompiler (Sass, Less, Stylus) can do?
I couldn't think of a very good example, but here's something: http://codepen.io/anon/pen/vuyAI
The CSS use a couple of custom properties that define the foreground and background colors. Then, some elements redefine those custom properties (through CSS or JS) and that in turn makes all their children inherit the new custom properties' values and change their styles. This makes the rules that use the custom properties very general, and avoids the need to write more specific rules for the alternative colors. I hope this makes sense :)
I don't think this is possible to do with CSS preprocessors.
Re: CSS Variables in Firefox 31 – new syntax
#49Earlier quoted context omitted.
As other posts have stated, CSS variables are not the same thing as preprocessor variables. Specifically, they cascade. A preprocessor cannot possibly implement CSS variables with cascading because it the value is resolved against a live context. In other words, you can actually change the variable at runtime with rules that target different selectors. As such, the "variables" are in fact functions.
Thanks for the break down. I'm not seeing the benefit of variables cascading, though.
I agree, I need to see a use-case for having cascading variables. The fact that they do seems to go against some of the benefits of them in the first place.
Re: CSS Variables in Firefox 31 – new syntax
#50Writing your styles in javascript is a better option. You get variables, as well as functions and modules (e.g. with browserify), all with sane syntax and semantics (no "cascade"). Preprocessors are an inferior solution, limited by the semantics of CSS and leading, by the pervasive use of macros, to needlessly large CSS file sizes.
What's the best solution for writing styles exclusively in JS and avoiding CSS completely?
I've made this argument before, using JS exclusively for styling does not let you avoid CSS. It lets you avoid certain aspects of CSS that may, or may not, be helpful.