One of the wonderful things about CSS is that because it's a domain-specific language, it can afford to be 100% declarative, with 100% deterministic behavior, and doesn't need any exceptions to be made or trap-doors to be added. The trap-door is JavaScript.

So, the more things you can move over into CSS, the more things exist in this beautiful pure context that's highly debuggable thanks to modern browser tooling (and that's not even getting into the performance advantages vs doing things in JS).

Put simply: it's really exciting every time CSS gets a new "real programming language" feature, even if these things are basic and familiar in other programming contexts. In this case we're not really getting a "new" feature, but people are used to thinking of CSS variables as like, a theming mechanism. I for one had never thought to use them as an API data format. The author is probing the boundaries of what's possible to do with them, and that's exciting and interesting.

As an aside: there's also a huge community that loves to just push and abuse HTML/CSS as far as they can for the sport of it. CSS-Tricks and its sibling-site CodePen are at the center of that community. To people like that, the idea of an API endpoint that uses a stylesheet to relay raw data for arbitrary usage is pretty cool.

If you add enough "real programming language" features, aren't you going to lose the "wonderful thing" you cite about CSS?

Not if you don't add state/control flow. That's the key. That stuff is exiled to JS-land.

And by "state" I mean it in its proper sense: something where CSS itself can mutate its own state. The OP calls CSS custom properties "state", but they're really just "constants" in the context of CSS itself (they can only be mutated by JS).

I'd argue that css already has (very limited) control flow [calc() statements, and the cascading nature of selectors]. In combination with user interaction and html, it also has state.

For example see the css implementation of celluar autonoma http://eli.fox-epste.in/rule110/

CSS has expressions, but not imperative logic or mutability (it's possible I misused the term "control flow")

You're right that HTML (technically, the DOM) has a little bit of intrinsic state, despite our mental model of it being static. However that state is constrained to user interaction and is always very localized, so it avoids most of the maintainability problems that we think of as coming from having mutable state

Yes, at some point. Check out, for example, dhall (https://dhall-lang.org/) to see where the sweet spot lies.

A lot of web front-end development these days is just very elaborate costume parties for global variables.

wait until you hear about the song and dance needed for a modern React app

That's my point though, react has an actual song and dance. This is literally just using a feature literally named "variables" to store data, as if it was like a variable or something.

> (rip cache)

You'd have a separate theme.css that defined the new variables. Because of CSS variables you can keep the main style.css and all the markup the same.

True, but you still cant do first paint until all css is loaded, and for people with fast connections, the latency of the extra roundtrip matters more than the size of the file downloaded (within reason)

An alternative would be keeping theme state in JS as suggested at the end of the article which improves the cache-ability of the css file as themes change.

Yeah you'd have to load it in async to avoid that. You could start with a gray base and have the theme color pop in. Flash of original color.