Because JavaScript requires… a lot. A virtual machine, script parsing, etc. Making that a requirement before you even display any content on the page would be a regression.
Google said they weren't smart enough to implement it, or pay anyone to fix the one they forked a decade ago.
To me it feels like "programming in YAML", the way a declarative language/format acquires more and more features until you're writing functions in an awkward syntax that was never designed for it.
At an initial look I agree with you that the functions look very awkward. But I thought the same about CSS variables until I started using them and now I think they’re great so I’ll keep an open mind. I almost wonder if they would have been better off calling them “templates”, or something. “Functions” is going to make people think it’s just like JS.
Perhaps I should also be sympathetic to the spec authors, since they're working under tight constraints of language design. Things might look a lot more elegant if HTML/CSS/JS were designed from scratch as a coherent whole.
https://developer.mozilla.org/en-US/docs/Web/API/CSS_Paintin...
It’s Chrome only though.
I've always wished more of the underlying CSS functionality were exposed to the scripting side, like calculating flex/grid layouts, without necessarily tying it to performance-critical painting path. Usually more expressive power means more responsibility, but there are already web APIs that do it in a controlled way, like request animation frame. So I can appreciate the potential of the Painting API and others in a similar direction.
At the same time, I also wish there was effort in the complete opposite way, to start over "from scratch" and make it easier (or possible at all) for people to build alternative browsers with a minimal subset of CSS. Perhaps something like a modularization of web technology, where the current hugely complex system is broken down into reusable libraries for building small and large browser-like applications. I know something like that exists, like Servo etc., but much smaller and simpler building blocks.
The worse part of working with CSS is that there is no standard static type checking tool (stylelint comes close though). A lot of programming errors should/could be caught at build time.
Sometimes wondering if a completely alternative syntax+tooling is possible that would leverage all the existing capabilities, while using a different language paradigm.
(element doc
(make paragraph
font-size: 20pt
line-spacing: 20pt
font-weight: 'bold
color: color-purple
(process-children)))
That's actually something you don't necessarily want: https://www.w3.org/2001/tag/doc/leastPower.html ... then again, once you hit turing-completeness and people start relying on it, you probably also have to admit that you're already soaking in it and you may as well make it pleasant.
I love that he used the word "axioms", especially these days when mathematical logic and mainstream software development seem to be reaching toward each other through type systems, static analysis, verification and so on.
That design document about "least power" is fascinating, it's a classic tension in programming language theory about expressivity and the value of constraints.
Reading about how HTML and CSS were intentionally designed to not become a programming language, it's funny to compare with modern web dev practices like React and CSS-in-JS, which re-envision what the separation of concerns means, very different from what the language designers had in mind.