Internet Explorer used to support "CSS expressions" that worked (work?) much as you describe. This was never widely adopted by developers, other browsers, or standards bodies.
The general principle for why this is not a good design is called "separation of concerns", which is something the W3C in particular has always strongly promoted. The idea is that the language for defining abstract content (HTML) is completely independent of the language for defining visual appearance (CSS) and the language for dynamic behavior (JavaScript).
Although it often feels like it would make sense to put "quick" calculations directly in your CSS, rather than creating a separate script, in practice this causes a lot of problems, for example:
- it is more complex to understand how JS and CSS interact; which code runs first, do JS properties reflect the calculated value or the expression itself, etc.
- it duplicates work that has already been done in creating JavaScript
- CSS becomes even more complicated to implement, and likely slower and buggier
- Since CSS is not designed as a programming language, it will be harder (if it's even possible) to understand and control when code runs; in practice this is likely to mean expressions being recomputed more often than they need to be
- CSS becomes a new vector for security issues, especially if the expression language is Turing-complete or close to it
IE's implementation reputedly had terrible performance for these reasons (like most people, I never seriously used it). It was essentially just a way to embed JS in CSS files, and as such it didn't work with scripts disabled.
You might argue that there's still a case for "simple" expressions like your example, and that this doesn't require a Turing-complete syntax. But however you define "simple", there will always come a point where your desired expression isn't "simple" enough and you have to migrate everything to JS anyway. The logical choice is to have CSS handle only constant values (making it as simple as possible to implement), and use JS for any dynamic calculation.
So the short answer is: the W3C, and individual browser vendors, considered this direction for CSS and concluded that it would do more harm than good.
ETA
Re-reading the question, it's not clear if you were talking about general expressions (like width:element1.width*2
), or just straightforward symbolic values. CSS-Variable does let you use macro-type variables, which makes stylesheets easier to edit. However, it doesn't let you, say, set the height of an element to the actual rendered height of another element; that would involve a potentially complicated run-time calculation, and for the reasons mentioned above, this is better done via JS where you have control of when the calculation is made, how to account for CSS transformations, and so on.