Looks to me that the existing system is better at providing Themes? It allows real code, inheritance, etc. to set variable values.
That is, I think Extension Themes are better off writing PHP Post-Processor rather then CSS vars.

Anyway, this transformation can probably be done incrementally, by creating a base CSS file to translate php variable to css variable, which will enable the css vars to be used everywhere.

But, I fear that at the end of this road, we'll have exactly the same capabilities we have now...

@avivey CSS vars are a vital part of modern modularized theming. They are versatile, can be overwritten with media queries or per class/element basis. They are editable in browser dev tools. If you would ask me: this step is pretty important.

The idea of leaving the vars in a theming class is a good one. Maybe the theme class can provide a theme css classname which will be used on the body tag. With this class it would be possible to overwrite all kinds of phui classes without using important inside a dedicated CSS theming file.

And my general approach is: when the client can do something (and that even better), why should the server do it?

The overwriting of variables with media queries could be configured inside the theming class. So possible breakpoints can be part of a theming API.

Ok, I don't understand the specifics of css-vars, but if they're better, they're better.

For the discussion about server v client: The reason for server-side everything has traditionally been that the clients are out of our control, and they suck. They suck less now (that there's only one actual browser in the world) then 5 years ago, but still.

This mostly applies to javascript, not so much for css; But the argument of "let the client do it" often goes down the path of writing huge javascript apps that are slow to download, and once they're done downloading, they start querying the server for data, and only then start rendering. This is why modern sites are so slow (I'm looking at you, Facebook!).
Phorge is quick to provide usable pages, because it does everything server side and can respond to the first http query with a page that's fully ready.

This doesn't really apply to css, but it's an important point in the architecture of Phorge.
Specifically, I expect we use post-processors and not css-vars just because they weren't ready last time this was visited.

Well, I see a tremendous critism and scepticism concerning modern client side techniques here. The world of frontend tooling has changed tremendously in the last 5 years. And I understand concerns, but nobody has to write JavaScript for certain browsers anymore. Javelin for example tries to solve so many problems that Babel solves with one config entry. But that's okay and I like the architecture here and know we can't change everything at once.

Real CSS vars can solve following problems the current system can't:

• they can be overwritten in media queries and with every selector
• they can be used in other css functions
• they can be changed in the dev tools

Here a nice writeup: https://prism55.com/thinking/pros-and-cons-of-css-variables/

A big benefit of using client-side variables in CSS, is that one can use the browser's prefers-color-scheme media query to select light or dark mode based on the user's browser or system setting, automatically, and that the transition from light to dark mode, or to other accent/highlight color schemes, requires no reload.

I'm not against replacing the mechanism - It's just that the original task description doesn't specify why that would be good (i.e., what the benefit would be).
That's clear from the discussion now, but should generally be included in the ticket description - the "describe "what", not "how"" principle.