Utility-first CSS is all the rage these days. Does anybody have feelings about what the next evolution of CSS (or web styling in general) will be?
What is on the horizon? Or, at least, what problems still need solving?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (49)
I think a lot of things that folks like about tooling are coming to CSS or are at least being discussed.
For example, in SASS, you can nest CSS rulesets.
There is a working draft of this for CSS.
Scoped styles which some CSS tooling does and a lot of CSS in JS frameworks do has a working draft as well.
Aside from that, there are more pseudo selectors and classes. The :has() pseudo-class gives us something folks have wanted for a while. A parent selector.
Just like the browser APIs adopted jQuery APIs or were inspired by them, the same appears to be happening for CSS.
All these improvements mean that you can do a lot more in CSS without relying on JS for a lot of things you had to in the past.
That working draft on CSS scoping is very outdated. Afaict it was very much dead for the longest time, and only recently got revived in the working draft of CSS Cascading and Inheritance Level 6
Nested selectors is about time. I'm not sure about :has() since it makes the rendering engines more complex algorithmically, possibly degrading performance, or ...?
At the very least, I'd expect
:has()to have no performance impact where it isn't use. If that can be achieved, and it just turns into one of these features that shouldn't be overused, but won't instantly kill your whole website, then I wouldn't mind having it as a feature tbh.This is the fundamental problem.
:has()does have a performance impact even where it isn't used. When a DOM element is mutated, the cascade needs to be recomputed. Without:has()implemented in browsers, only the cascade of the descendant elements of the parent of the mutated element needs to be recomputed. With:has()implemented, it was believed that the cascade of every element in the DOM would need recomputing, even if:has()wasn't used in any selector. The work done recently to implement:has()was essentially about finding a way to short cut that process to minimise the amount of the cascade that needs to be recomputed. But it can't be entirely eliminated.Similar ideas is the reason why Hyperlambda is so blistering fast, because parsing only implies "forward operations", and nothing during parsing can change anything backwards in the file, which of course allows the parser to exclusively look forward ignoring everything it's already seen. Thank you for re-iterating that fact ...
It's super easy:
:has()somewhere in them:has()applies to/s
utility-first it not an evolution. It's only a trending as it doesn't add anything new to CSS.
The future of CSS is:
And many more
One thing I read recently that amazed me:
From: w3.org/Style/CSS/draft1.html#arith...
This is a proto-
clamp()! In the very first draft of CSS in May 1995. Before declaration blocks had even been invented, or CSS syntax had been established.calc()combined withvar()and@propertycan be used to build amazing things without any need for pre-processors.Sometimes I feel like CSS is basically the Assembly language of styling, writing lots of code to achieve small "ideas" such as overlap, gridding, theming, and whatnot. Flexbox, Grid, etc I think have gotten us closer to this more-or-less declarative approach, where our code better reflects what the design really wants rather than just serve as a means to achieve that design.
Old-school CSS was very much about compiling esoteric idioms for simple design concepts into actual designs (
floatet al.), but these days the language has idioms for most of the common design patterns, so writing CSS is much more about actually describing the design and less about fighting the available paradigms.Yep, exactly! Another example I thought of is
aspect-ratiowhich is a great idiom for ideas like "I want a square", and superior to 100% bottom padding jank.I do still find myself occasionally wishing for a better idiom (such as for overlap where you have to choose between absolute positioning, negative margins, or things sharing a grid space), but it's way better than it was a decade ago, and why I think it'll keep getting better.
Yes, a
content-overlapproperty would be pretty nice.I think it's worth noting that CSS was, initially, effectively a language for print-style layouting. No one really intended for it to work with viewport-covering areas or boxed layouts in the sense we're used to now. We abused the living hell out of it by exploiting the underlying rendering algorithms, e.g. using float to create column layouts, or using table layouts. The rest was what HTML and framesets were meant to take care of.
Good observation, sometimes CSS feels incredibly low level and a lot of non-intuitive hocus pocus is needed to achieve the simplest things ... a lot of that is due to its origins as a page/text styling language, it was never designed with application development in mind ... but (as you already noticed) recent developments like Flexbox and CSS Grid have indeed tried to improve on this situation!
CSS is getting really good at describing reactive, context-aware layouts. New stuff like
:is(),:where()and:has(), as well as cascade layers solve scoping across components. Container Queries solve compenent-scope layouting. Auto-fill and masonry grids provide layouting algorithms. There's a spec for full-on if/else. We have variables. Is described some of that in my post about it: dev.to/iamschulz/writing-logic-in-...I hope we can overcome the current trend of utility-first css. That approach really limits the possibilities of those new features.
Being a pessimist though, I see more tailwind and CSS-inJS.
More and more terrible things will become "all the rage".
The web will get incrementally worse until it's only understood by AI parsers.
All hope will be lost.
Junior Developer mentioning Tailwind CSS in 3, 2, 1 ...
Hey, I feel this is the future of CSS
Web developers who know CSS are in high demand for businesses. In fact, according to the Bureau of Labor Statistics, web development is a profession expected to grow much faster than the average occupation over the next decade.
It's still hard to test styles in an effective way. I'd like that to be an evolution.
dunno if it's the horizon, maybe a part of it at least, but I look forward to using Container Queries. Context and container that react to changes could have a significant impact on component-based projects.
Still early stage, though.