Does anyone know if the var() function only work with the variables? For example, can I do something like: background-color: var(color);?
Doesn't work.
CSS Variables in Firefox 31 – new syntax
31–40 of 54 posts
Re: CSS Variables in Firefox 31 – new syntax
#32Earlier 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…
This is just stupid. Here are some sigils they could have easily used without much issue: #, *, +. They could have also used something like [var-name] or .
I am convinced that at this point CSS is a clusterfuck that should be killed with fire.
Re: CSS Variables in Firefox 31 – new syntax
#33Writing 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.
And does your styling work in a webbrowser where JS is disabled?
Re: CSS Variables in Firefox 31 – new syntax
#34Earlier quoted context omitted.
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…
From the second link in parent: "> As far as I understand, the main reason of why Tab's original idea of using `$` has eventually been dropped was some uncertainty about its possible extensibility for being used in property _names_ besides property _values_. The reason it got dropped is that some people (including Tab) do believe we should reserve $ for mixins and other preprocessor-like operations which may potentia…
I don't get that argument. Sass manages to avoid $ conflicts while using it for both variables and mixins. Its nice clean, consistent syntax. I don't see why we need different syntax for the two. Eg:
$myColor: #fff;
a {
color: $myColor;
}
@mixin border-radius($radius) {
-webkit-border-radius: $radius;
-moz-border-radius: $radius;
-ms-border-radius: $radius;
border-radius: $radius;
}
.box { @include border-radius(10px); }Re: CSS Variables in Firefox 31 – new syntax
#35Earlier quoted context omitted.
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…
This is just stupid. Here are some sigils they could have easily used without much issue: #, *, +. They could have also used something like [var-name] or . I am convinced that at this point CSS is a clusterfuck that should be killed with fire.
And one thing we should kill it with is GSS. (http://gridstylesheets.org)
Watch the video!
Re: CSS Variables in Firefox 31 – new syntax
#36Earlier quoted context omitted.
I think this is just a problem of nomenclature. In CSS, a statement such as font-color : red; comprises a "property" (left) and a "value" (right). The draft W3C proposal allows you to specify a "custom property" and assign a value to it, thus: --header-bg-colour : #ff5533; You can then reference this elsewhere by saying: header { background-color : var(--header-bg-colour); } Isn't that just how you use a variable (wr…
The similarity is only superficial. SASS variables are lexically scoped. CSS properties are cascading.
There is that. Over in the real world, I suspect most people will put their CSS variables in ::root and leave it at that.
Re: CSS Variables in Firefox 31 – new syntax
#37Writing 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.
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?
Re: CSS Variables in Firefox 31 – new syntax
#38Writing 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?
My practice is to build the DOM programmatically with jQuery, and add styles to the elements directly
$("")
.css({width: 100, height: 20, color: 'red'})
.appendTo(container);
Most styles in the applications I write tend to be inextricably linked to the layout and function of a component (e.g., tabs should be next to each other); in the rare case that a style needs to be customized in different locations or at different times, it becomes a parameter (e.g. `confirmDialog(textStyle, message, onOk, onCancel)`)
No extra tools are needed, beyond jQuery (building up the DOM without jQuery or something like it is awful).
Re: CSS Variables in Firefox 31 – new syntax
#39Earlier 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?
Viewing some overly crufty sites can benefit from having JS completely off rather than "simply" using an ad-blocker. I'd wager that some tinfoilhats still run with JS off, or at least NoScript almost everything.
Re: CSS Variables in Firefox 31 – new syntax
#40Can anyone think of a use case for this beyond what a precompiler (Sass, Less, Stylus) can do?
Because precompilers are sort of a disruption of the point of CSS to begin with. I know, I know, a lot of people use them, but using style sheets that require compilation pretty much defeats the purpose of separation.
Yes and no. The browser has to parse the CSS, and it's most likely building an abstract symbol tree. So in a sense CSS is compiled too, it just happens in the browser so web developers don't have to be aware of it.
Do you remember the type attribute?
...