I'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
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 )
Ah, Bert Bos, the W3C's "style activity lead". What a joke.
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?
To be fair though, I should also say that nowadays the CSS working group has a lot of very smart people who absolutely understand the needs of web developers/designers, and have been tireless in getting things like Flexbox specced and implemented across different browsers.
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.
> 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.
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!
Didn’t Firefox have actual SASS support for some time? I think at least the dev tools had support for SASS source maps, but I’m not sure if the browser actually had support.
Properly, the --foo stuff is a Custom Property. You can use its value as a variable, with var(), but it's not the only use custom properties have. That's why the spec's full name is "CSS Custom Properties for Cascading Variables". But that's a horrible mouthful, so "CSS Variables" is what it's usually called. (Plus that's the shortname in the url.)
(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.)
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 )