:root { --color: blue; }
    div { --color: green; }
    #alert { --color: red; }
    * { color: var(--color); }

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]

[0] https://developers.google.com/web/updates/2016/02/css-variab...

[1] http://cssnext.io/features/#custom-properties-var

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

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]).

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.

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

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 )

Meanwhile Smashing says something like 77% of audience uses SASS.

He's the guy who wasted a decade writing an ASCII-art based "template layout module"[1], which he was never able to persuade a single browser vendor to implement. It eventually got demoted from a working draft to a "note", which is the W3C's polite term for standards fanfiction.

His other major achievement is putting his own photo on every one of the CSS working group's web pages. I'm not joking: https://www.w3.org/Style/CSS/#endmatter .

And let me tell you tale of that photo/byline. It originally appeared on the working group's crappy 1990s site, which persisted until the late 2000s (because that's how fast things move at the W3C), and you could kinda forgive it as one of the dumb things people put on dumb 1990s websites.

Anyway, eventually it became too embarrassing that the working group responsible for CSS had such a shitty site, and some other members of the group took it upon themselves to produce a shiny new design with useful content, but sans Bos' photo. This done, they submitted what they'd come up to the W3C. Eventually, it showed up on the W3C's servers but, surprise, surprise, it had been rather mangled, and Bos' photo was back, clumsily shoved into a footer where it hadn't originally been.

It's a small, petty thing, but all the more hilarious for it. God knows how that guy still has a job at the W3C. Maybe he's best friends with Tim Berners-Lee, or something?

[1] https://www.w3.org/TR/css-template-3/

CSS is about a decade behind where it should be, but that's not the fault of the people working on it now. And I think its future is actually comparatively bright, especially with the Houdini project taking off.

This is because it was absorbed into the larger and more fleshed-out Grid specification, which is nearly release-ready in multiple browsers. The ASCII art is actually really useful!

Hahaha, wow.

(There's also a large focus, in v1 here, on the variables use-case, because that's what I needed to sell it to the group at the time. The CSS Houdini Task Force is now expanding Custom Properties properly, so they can actually be used for random JS things without a ton of hackery.)

  .foo {
    &--bar {
      --bar: 0;
    }
  }

http://www.xanthir.com/blog/b4KT0

We could only have used $foo if we hewed very close to Sass's functionality - global macros that operate at the stylesheet's lexical level. That wasn't what we wanted to do, though, either at the time (considering only the variables use-case) or looking forward (to the use of custom properties as the generic "inject info into your page via the CSS engine", a la data attributes for HTML).

By avoiding global macros, we also get context sensitivity - we can actually offer APIs for this stuff that are smarter than "here's the string you set". When we add custom pseudoclasses, custom media queries, etc they'll all get their own useful APIs. Sass is stuck with string manipulation, because you can use a Sass var anywhere, so it's impossible to infer anything about it.

It's nice if you really want to utilize the current syntax, but it's less powerful than either option it's derived from.

It works in every browser today, and even old browsers, INCLUDING IE8!

http://elementqueries.com/demos/variables.html

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.

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.

Well, Windows 7 and 8.1 will receive support until 2020 and 2023 respectively. That gives us at least four years of IE 11 being the "new IE 6." (Yes, that is a bit of an overstatement, I remember the horrors of IE 6 quite well. It's still disappointing.)

But Edge updates seem to be a lot rarer than people expected, and seemingly tied more into Windows updates than any sort of regular release schedule.

If Microsoft want to make it a good browser in the long term, they need to move away from tying updates to Windows ones and just release them when new features have been implemented.

    color: var(--primary-color);

    let value = styles['color']; // 'red'

So of course you have to know the name of the variables, they're an API for your CSS.

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().

[1] https://www.broken-links.com/2014/08/28/css-variables-updati...

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.

The additional options for self harm are well offset by the features.

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.)

The problem was that every old browser had its own API and feature set. Jquery abstracted over all that, including bugs in specific versions of browsers and continually is updated to handle the case of a browser claiming to implement a feature but lying.

Really if all browsers had the same API and feature set, there'd be no need for jQuery as it is today; you'd have a very different library.