9 ms·
CSS Variables landing in Chrome 49
- TazeTSchnitzel 11y agoThey're already enabled in Firefox, and they'll also be supported in the next version of Safari. I'm going to use these to allow changing the appearance of my app, which has a Windows 95-style UI. 95 has many customisable values that determine how the UI looks (fonts, font sizes, font styles, foreground and background colours, UI element sizes, etc.) that it stores in certain registry keys and that the user can change from the Display control panel applet. In my app, I'll be using CSS variables in place of registry keys.
- jordache 11y agoyou are using reg keys to store properties? is it a chromium app?
- dEnigma 11y agoHe was just explaining how it worked in Windows 95, he will be using CSS variables instead.
- TazeTSchnitzel 11y agoShe, and yes, that's the idea. I couldn't explain it very clearly.
- dEnigma 11y agoSorry, I always default to the male form for some reason.
- ry_ry 11y agocustom props beginning with 2 dashes is slightly annoying given the BEM syntax has already grabbed that as Modifier... .foo { &--bar { --bar: 0; } } It's a pretty contrived example, but akward to comprehend at first glance.
- deleted 11y ago[deleted]
- supernintendo 11y agoOk, that's cool. How long until we're able to use this and not have to worry about browser incompatibilities?
- crisnoble 11y agoIt depends on what browsers you need to support. Based on this data http://caniuse.com/#feat=css-variables http://caniuse.com/#feat=css-variables I think it will be quite some time before you see this in sites that need broad browser compatibility. Surely there will be (is?) a shim that will come along.
- estefan 11y ago~5 years depending on who you're targetting.
- currysausage 11y agoPretty sad that in a world with living standards and silent updates, things that improve the state of the Web so vastly for developers still take so long to be widely available. (W3C doesn't even have a CR yet.) Less and Sass are nice, but the resulting CSS is full of repetition, thus hurting performance. Am I right in assuming that IE won't receive any more feature updates? Many enterprises will stay on Win 7 for a while and enterprises traditionally embrace IE, so thank you, "new" Microsoft, for pushing things forward.
- CM30 11y agoGiven that Edge has pretty much completely replaced IE, then yes, it's unlikely IE will receive any more updates. And to make it worse, Microsoft doesn't seem to be updating Edge as much as they were promising, meaning that we could end up in the exact same situation as before.
- EvanPlaice 11y agoEdge is an evergreen (ie auto updating) so it's a very good thing that MS is aggressively pushing to kill IE. In the not-so-distant future, IE won't exist. Safari will likely be the next browser that will be slowest to update, considering its current progress in relation to the latest standards. Even with regular updates they seem to be falling behind.
- givan 11y agoThe syntax is verbose and ugly compared to SASS
- colinramsay 11y agoI think a lot of people agree with you but there is a reason: http://www.xanthir.com/blog/b4KT0 http://www.xanthir.com/blog/b4KT0
- frik 11y agoStupid decision, the should have used $foo (dollar sign for variables) like in Perl and PHP. It remind me decisions of standards based on XML (XLST, XML-Schema, RDF, etc).
- deleted 11y ago[deleted]
- esailija 11y agoRead the linked post. Css variables are nothing like macros like sass's `$foo` and css might support macros with sass's `$foo` syntax in future.
- frik 11y agoI read the article, that's why I commented because "might support something in future" that probably never happens, is what I related to XML based formats design decisions go wrong. Argh, but thanks for misunderstanding and downvotings.
- innocentoldguy 11y agoI understand the reasoning, but this new syntax is still kind of verbose and ugly. I think one of the reasons Sass has been so successful is that it is elegant. It adds a lot of functionality to CSS, but does so in a way that feels very much at home. This new syntax doesn't feels very elegant and it doesn't feel at home with current CSS syntax.
- SwellJoe 11y agoI've wondered for years why we're using pre-processing to get variables into CSS. Given that there hasn't been a commonly advocated workflow that didn't include some sort of CSS processor (like LESS or SASS) in about a decade, it seems like somebody working on the standards would have realized that CSS needed variables, at the very least. So, it's cool that it's coming, though it's taken a lot longer than I reckon it probably should have. I would normally say, "But, at least there's been time to work out the syntax in non-core projects, so things are probably nice now." But, this syntax and behavior doesn't even resemble SASS or LESS. Is there some other tool out there that provides variables in CSS that this is modeled after? Why reinvent the wheel when so many people are already familiar with and have worked out the quirks in SASS or LESS? Reading the explanation for why they went this way (in short, because these are nothing like SASS variables, in the sense that SASS is more like a macro): http://www.xanthir.com/blog/b4KT0 http://www.xanthir.com/blog/b4KT0 Is somewhat unconvincing. Why not implement what's already working for people in SASS/LESS (in the way it's already working), and then move on to whatever it is they've implemented here later once it is clear it's something people want/need and once it's been worked out in pre-processors? (I don't think I quite grasp the entirety of the difference, either...is it merely a matter of scope and composability?). Actually, someone in the comments maybe sums it up: "In fact, let me see if I've got this straight in my head: CSS preprocessors added a feature called variables, but which would more accurately be described as macros. Browser vendors and the working group worked sporadically on an in-browser implementation and standardisation of this macro feature, and they also called it CSS variables. The WG's focus shifted to a feature more akin to custom properties, but which retained the name CSS variables. So, right now we have CSS variables in preprocessors, which are macros, CSS variables in browsers, which are custom properties, and maybe at some point in the future, macros in the browser, and actual variables in the browser." (Source: http://www.xanthir.com/b4KT0#4KT0-13 http://www.xanthir.com/b4KT0#4KT0-13 )
- nailer 11y agoThe CSS team has people like this, who no longer make websites: https://www.w3.org/People/Bos/CSS-variables https://www.w3.org/People/Bos/CSS-variables Thus they're disconnected from current web developers. Meanwhile Smashing says something like 77% of audience uses SASS.
- deleted 11y ago[deleted]
- lcnmrn 11y agoJust add native support for Sass and call it a day.
- EugeneOZ 11y agoSASS encourage developers to build long chains of selectors and it makes them brittle and non-reusable.
- ry_ry 11y agoYeah, it's easily abused and trivial errors of judgement create non-trivial problems later down the line. IMO part of the problem is that nested LESS/SASS looks just enough like JSON to mislead inexperienced devs, who often try to treat the nested structure as an object, rather than thinking of it as a string-builder. It invariably ends up creating huge swarths of pointless specificity and stylesheet bloat.
- ferdamravenec 11y agoCSS offers plenty of ways to hang yourself without resorting to SASS. The people who are dangerous with SASS tend to already be just as dangerous with plain CSS, in my experience. The additional options for self harm are well offset by the features.
- steveax 11y agoAmong other problems (perf, etc.) you'd have the application/xhtml+xml problem all over again, this time in styles.
- TabAtkins 11y ago"Just add native support for jQuery and call it a day" "Just add native support for React and call it a day" We can do lots of amazing things in the ecosystem, but often we're working around missing primitives in the platform. Just "adding native support" for today's hottest library doesn't fix things properly. It's better to figure out what problem they were solving, and then fix that problem more directly. (jQuery is largely solving "DOM APIs suck". We've fixed that a little bit, with things like query() (née querySelector(), which was an awkward first attempt at it) and fetch(), but are still struggling to work through browser dev apathy at things like event registration or creating elements.) (Figuring out what problem, precisely, React is solving is exciting and interesting. It's non-obvious - it's not just "some DOM things are slow", as there's lots of DOM things both fast and slow, and you don't need a fancy (read:slow) tree-diffing algo to fix those. There's something fundamental going on that we might be able to do better - maybe it's more fully separating the "display thread" that contains DOM from the rest of your JS, and letting you do a lot of DOM-ish manipulation in threads other than the display thread. Maybe that means actually using an even more lightweight display abstraction, so you can cheaply spam out updates without having to do expensive diffing first. There's a lot of possibilities here.)
- bsimpson 11y agoWell, that was a long time coming. I was playing with a beta version of CSS Vars 4+ years ago, which was then removed and eventually replaced with this.
- mendelk 11y agoFor those commenting about SASS having this forever etc, note that this goes a step further: :root { --color: blue; } div { --color: green; } #alert { --color: red; } * { color: var(--color); } You can't accomplish that with SASS today. More info [0]. In fact, this feature isn't even covered with cssnext: The current transformation for custom properties aims to provide a future-proof way of using a limited subset (to top-level :root selector) ... [1] I'm very curious whether or not this paradigm will be accepted as "best practice", or how it will be used. [0] https://developers.google.com/web/updates/2016/02/css-variables-why-should-you-care#the-cascade https://developers.google.com/web/updates/2016/02/css-variab... [1] http://cssnext.io/features/#custom-properties-var http://cssnext.io/features/#custom-properties-var
- wanda 11y agoDon't forget that CSS Variables can also be used within media queries.
- masklinn 11y agoAnd if you change a CSS variable in JS, it will recompute all of its uses.
- madeofpalk 11y agoIf you're interested in seeing what happens next with CSS Variables, check out the CSS Houdini project https://drafts.css-houdini.org https://drafts.css-houdini.org It starts with a JS API for more control over CSS Variables (which are actually called Custom Properties), and then goes into APIs for custom renders and even custom layout engines, all controlled via JS + Web Workers
- cdata 11y agoAlso on the topic of things SASS cannot do: Custom Properties effectively enable "styling APIs" to be declared for Custom Elements that have a shadow root, since Custom Properties cascade across shadow boundaries (detail in parent's [0]).
- Negative1 11y agoWhy don't they just natively support realtime compilation of SASS/LESS?
- ry_ry 11y agothe performance would be horrible.
- hanniabu 11y agoI'm not a fan of this... /* JS */ var styles = getComputedStyle(document.documentElement); var value = String(styles.getPropertyValue('--primary-color')).trim(); // value = 'red' Rather than calling '--primary-color', you should really be able to call 'color' which points to the variable and will still return red. Otherwise you'll have to know the name of each variable being used, which is much more difficult than knowing the property.
- masklinn 11y agoThe point of variables is that you can reuse them, and more importantly changing the variable dynamically changes all of its uses. So of course you have to know the name of the variables, they're an API for your CSS.
- spankalee 11y agoVariables are ultimately used somewhere to set a property, with something like color: var(--primary-color); If care about that property, and not the variable, then get it as usual: let value = styles['color']; // 'red'
- TazeTSchnitzel 11y agoWell, you can also get the computed style for 'color'. What ever made you think you couldn't?
- TabAtkins 11y agoThat's exactly what you can do. var() is replaced at computed-value time, so calling gCS().color will return "red" or whatever. If you use an API that gives you the value at an earlier time, like el.style.color (which is "specified value"), you'll see the var().
- ape4 11y agoIs there a way to access it from javaScript? Can JS code set CSS --color and make it change.
- pygy_ 11y agoYes, it's mentioned in the article.
- saulr 11y agoIt looks like this can be changed with `setProperty`. There's a demo[1] that works on Firefox 31+ and Chrome 49+ [1] https://www.broken-links.com/2014/08/28/css-variables-updating-custom-properties-javascript/ https://www.broken-links.com/2014/08/28/css-variables-updati...
- ape4 11y agoThanks. I wonder if it could be creatively misused to act as a database.
- deleted 11y ago[deleted]