8 ms·
CSS Variables land in WebKit
- VMG 14y agofrom http://www.w3.org/TR/css-variables/ http://www.w3.org/TR/css-variables/ :root { var-header-color: #06c; } h1 { background-color: var(header-color); } looks slightly hacky, but better than nothing at all I suppose...
- hellweaver666 14y agoIt's nowhere near as nice as the sass/scss/less syntax for css variables.
- randall 14y agoIt's not the css we wanted, it's the css we deserved. :) But seriously, this is extremely consistant with other css directives. Yes, I'm still going to just use less / stylus / whatever, but browser based vars mean some interesting possibilities sans js.
- SquareWheel 14y agoOh jeez, that's going to be really cumbersome to write. edit: I think I'll stick to PHP variables in my CSS for now: <?=$color1?>
- Hovertruck 14y agoYou do lose the benefit of caching with that approach, though.
- philfreo 14y agoYou don't have to. You treat it like you would with LESS - executes during development and you compile it for production
- Hovertruck 14y agoAt that point you should just be using LESS/SASS/etc, though, for the other niceties they provide for working with colors and such.
- btipling 14y agoThis is a terrible idea. Do you cachebust your CSS?
- SquareWheel 14y agoI generally make heavy use of both server-side and client-side caching. It really depends on the site. If it's just an internal company tool then I usually don't worry about intelligent caching. I understand the danger of introducing PHP to CSS though. I won't be making database calls or anything like that from a .css file.
- voidr 14y agoThis looks like crap, I am sticking to LESS. It's not worth standardizing half assed stuff like this. These standards groups should open their eyes and look around before standardizing something.
- untog 14y agoIt might be of use in CSS debugging, not that I have a huge problem debugging LESS files. But eventually perhaps there will be LESS -> CSS/variables we can test with.
- drivingmenuts 14y agoSeriously? Debugging in Sass is a no-brainer - it barfs as soon as there's an error and it's blatantly obvious as soon as you load the page, since the relevant errors are splattered all over the the top of the page (this is a good thing). This proposal by the W3C is definitely not-even-half-baked.
- untog 14y agoI don't mean debugging in the sense of "there's a compilation error", I mean in the sense of "oh, that box has a blue border? That's wrong- what line did I define that variable on?". As I said, it's not a huge problem right now, but in more complex files it can take time to track down the original definition that led to the CSS you're seeing.
- TabAtkins 14y agoSyntax isn't frozen. Here's another possibility: :root { $header-color: #06c; } h1 { background-color: $header-color; } (Note that the spec's use of the :root pseudo is just to generically declare "global" variables that should apply to the whole page. If you're just using HTML, feel free to use "html" or "body" as the selector instead.)
- bkardell 14y agoTo be very clear rhe one on the left defines, the one on the right uses.
- aboodman 14y agoOut of curiosity, why was the syntax in the current draft chosen over this?
- nilliams 14y agoThis syntax is clearly preferable, but I think you knew that or you wouldn't have written it :) I'm guessing the justification for the existence of the awkward var(varname) version is so that you can also have the parent-var(varname) notation. I do think it's interesting how variables are scoped to dom nodes. Is there any reason it cannot be optional though, so if you omit it, it defaults to global? $header-color: #06c; h1 { background-color: $header-color; } I'm guessing the argument against, is that this requires too much of a change to CSS parsers, as it doesn't follow the standard form of <selector> { <properties> }. If that's really the reason it seems a bit of a shame though :/
- bkardell 14y agoI disagree that it is preferable, but that is debatable. I say that in part for the reasons you mention, but also because it seems to me that quite a lot of people think that "$header-color" means "substitute the value of the header-color variable here" regardless of which side it is on. I think there is probably a happy middle ground where you achieve all of the goodness (looks like CSS, follows existing core grammar, shows the property nature, uses $ in familiar ways, etc). Not sure what it is, but probably something like: :root{ def-primarycolor: blue; } .x{ background-color: $primarycolor; }
- jontro 14y agoVery nice. I cant wait to use this feature. Putting color codes in one variable will help a lot.
- insertnickname 14y agoOnly problem is that no one else supports it.
- huggyface 14y agoYou have to start somewhere. The only real question is whether it can be added as a polyfill on browsers as they catch up.
- bratsche 14y agoNobody supports it yet and it's already done better using preprocessors like Sass. Your move, Sherlock.
- huggyface 14y agoI like the part where people get so attached to a tool that they've learned that they reject change. Like your message. Comparing a preprocessor to a native element is asinine. Do you argue against JavaScript features because, given that it's a turing complete language, such things could simply be done with preprocessors? Seriously the boorish comments about "no support yet" are like listening to fat client advocates in the 90s.
- jontro 14y agoAgreed, we are embedding chromium in our desktop apps. Here we can depend fully on the features this particular browser version supports. Cross browser support is not always necessary.
- bratsche 14y agoIt's not so much about attachment to current tools. It's just that you look at something like this, with all its cumbersome syntax, and wonder why they had to make it so ridiculous. And it's not like nobody had any decent ideas of how to do a nice, simple, clean syntax for variables. In the end I suppose we'll be able to continue using preprocessors, and maybe they can generate the clumsy native CSS variables, so it won't really matter and we'll get the best of both worlds. But it sure would be nice if they wouldn't create new features that instantly feel cumbersome to use compared to what people have already been using.
- dcolgan 14y agoI recently discovered Less (http://lesscss.org/ http://lesscss.org/), a CSS preprocessor that adds support for variables and many other features, like nested rules and mixins. Using Less has been one of the most profound upgrades in my use of programming techniques in quite a while. Hopefully browsers will eventually support even more Less-like features.
- culturestate 14y agoIf you like Less, you should try Sass/SCSS (http://sass-lang.com/ http://sass-lang.com/) - same idea, but a little more powerful. Here's a good head-to-head: http://css-tricks.com/sass-vs-less/ http://css-tricks.com/sass-vs-less/
- rescripting 14y agoSince we're listing alternatives, I prefer Stylus (https://github.com/learnboost/stylus https://github.com/learnboost/stylus).
- hackinthebochs 14y agoI look a look at the sass-vs-less link, and I really don't see the draw of either. I don't want a turing-complete language in my css. Simple variable expansion will suffice--basically just syntactic sugar. I don't want yet another game of "find the definition" buried under a hierarchy of indirection. Perhaps its a lack of imagination on my part, but I can't think of a good use of this power for the purposes of styling a document.
- masklinn 14y agoI completely agree with you. That said, you can restrict your usage of these things. On the project I'm currently working on, we're only using three features: 1. constants (mostly for colors and a few sizes) 2. mixins/functions/macros for not-completely-standard properties (e.g. gradients, shadows), makes it easier to not forget a prefixed version, easier to update the definition when needed and much, much easier to read 3. nesting and continuations, especially for styling various states of e.g. a link (having to copy/paste a given selector 4 times and change the pseudo-class is no fun). Still requires some care though, overusing e.g. nesting can mean you find yourself with fucked up huge selectors in the final file.
- nthitz 14y agoAny idea on when we can expect to see this implemented in Chrome or Safari?
- cleverjake 14y agowithin a couple days on chrome canary. It was in r120154, and the current OS X canary is at r120017. That little of a difference usually means a couple days at most. Safari on the other hand...probably a year or so. Possibly what comes after mountain lion. They won't add it in until it is fairly stable.
- huxley 14y agoApple also has WebKit Nightly Builds where it might appear sooner: http://nightly.webkit.org/ http://nightly.webkit.org/
- paulirish 14y agoRight now it's behind a compile-time flag and although I've asked to go on a runtime flag, we haven't seen that change yet. So.. it won't be available in canary for a few weeks.
- dhx 14y agoAn interesting feature is dynamic updating of dependent variable properties: This example shows a variable property safely using a variable: :root { var-main-color: #c06; var-accent-background: linear-gradient(to top, var(main-color), white); } The ‘var-accent-background’ property will automatically update when the ‘var-main-color’ property is changed. edit: clarified the wording of this comment to remove ambiguity (not a question).
- monkeyfacebag 14y agoTrivially, the difference is that neither SASS nor LESS is actually CSS and therefore must be transformed into valid CSS prior to being parsed by the browser. This would eliminate that step. EDIT: parent originally asked about the difference between this and SASS/LESS.
- sjs382 14y agoIt wont need to be compiled into CSS—it _is_ CSS? > EDIT: parent originally asked about the difference between this and SASS/LESS.
- chao- 14y agoI would welcome this if I hadn't finally just gotten on board the SASS train. All I see this doing (for some ill-defined span known as "the present"), is adding another layer of headache into the browser compatibility game. Furthermore, I agree with VMG that there's something to be desired in the chosen syntax.
- cleverjake 14y agoWouldn't that 'headache' be prevented with SASS until it is supported across the board?
- chao- 14y agoOh definitely. I just mean to express that I'm not as excited as I otherwise would be. I'm not fortunate enough to be working on the types of projects where that can say to our market "You can take your IE7 and hit the road!" Thus while I wouldn't have been using these variables anyway, I would still have been very excited.
- ch0wn 14y agoThere's more to it than what Sass, Less and co. can provide. It simplifies dynamically changing a bunch of CSS properties from JavaScript a lot. Instead of changing all the elements using a particular style, you could now change just the variable instead. This gets even more interesting when properties are composed of variables, like gradient colors. Also, this is a pretty high-level addition. I wouldn't be surprised if someone came up with a polyfill for this soon.
- chao- 14y agoThat's the biggest draw that I currently see. I would love to reference other features that SASS and LESS still bring to the table, but the idea of JavaScript fiddling with CSS variables is mouth-watering indeed.
- huskyr 14y agoI can imagine you could create one stylesheet for browsers that support CSS variables, and one for browser that don't.
- bendemott 14y agoHonestly, it seems the server-side solutions for css meta-syntax that supports variables are still more suited for this type of thing (such as SASS).
- underwater 14y agoMy issue with the spec the W3C settled on is that it contains nuances that mean it must be implemented in the browser. It is not possible to write a serverside preprocessor that implements the spec. Unlike other technologies like canvas or AJAX where we've been able to create polyfills for older browsers, authors will now have to make an explicit decision between either using CSS variables or supporting all browsers.
- wccrawford 14y agoCan you give some examples of things that can't be done by a preprocessor?
- JoshTriplett 14y agoVariable values can cascade like other CSS properties. So, you could define a theme via a set of variables, and redefine those variables in a CSS class ("selected items look like this"), or a media query ("mobile uses this theme"), or via JavaScript. That requires evaluation in the browser.
- superk 14y agoPreprocessors evaluate CSS and the cascade so there's nothing stopping them from adding local scope or specificity to variables. On the other hand, if you can really edit variable values with Javascript then that would be client-side only, although I haven't seen anything that says you _can_ do that - for all we know Javascript may only allow getting/setting of the evaluated value, not the variable expression itself.
- JoshTriplett 14y ago> Preprocessors evaluate CSS and the cascade so there's nothing stopping them from adding local scope or specificity to variables. That cascade depends on the structure of the document, not just the CSS. For instance, consider the following (contrived) example: :root { var-accent: black; } .someclass > :first-child { var-accent: blue; } .otherclass { background-color: var(accent); } .anotherclass :first-letter { color: var(accent); } The value of var(accent) for any element depends on whether the ancestors of that element include the first child of an element with class="someclass". For a preprocessor to duplicate that effect on the server side, it would need to construct all possible combinations of the selectors for the variables and the selectors depending on those variables: .otherclass { background-color: black; } .anotherclass :first-letter { color: black; } .someclass > :first-child .otherclass { background-color: blue; } .someclass > :first-child .anotherclass :first-letter { color: blue; } Now consider that with a dozen variables and a hundred variable-dependent rules. > On the other hand, if you can really edit variable values with Javascript then that would be client-side only, although I haven't seen anything that says you _can_ do that - for all we know Javascript may only allow getting/setting of the evaluated value, not the variable expression itself. The CSS Variables spec talks about dynamic variable updates via scripting.
- bkardell 14y agoCSS variables do something fundamentally different than SASS/LESS approaches. Moreover, it is something which those approaches are incapable of doing. Conversely, SASS and LESS do something that CSS can never do - be processed only once. Much of the confusion I think is in the fact that we are referring to two dramatically different things by the same word "variables". In CSS terms it is more helpful (IMO) to think of them more like "user defined properties" which work exactly like every other property in CSS.
- thechangelog 14y agoOr call what SASS and LESS do global constants.
- bkardell 14y agoYes, I agree, but too late for that change probably. Plus I'm sure someone will point out that they are not actually necessarily constant by strict definition either. An easier way to think about it is that they are essentially clever compile time template systems which output CSS... It's totally unrelated that their input also happens to look a lot like CSS - it isn't.
- Tichy 14y agoI really worry about the future of CSS. It already is the most difficult of all web techniques to use. Once they introduce the css scripting thing all bets are off...