DEV Community

Cover image for What is the future of CSS?

What is the future of CSS?

Ben Halpern on March 29, 2022

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?

Collapse
 
nickytonline profile image
Nick Taylor • Edited

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.

.some-container {
  .some-child-component {
    // insert awesome CSS
  }
}
Enter fullscreen mode Exit fullscreen mode

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.

Collapse
 
darkwiiplayer profile image
๐’ŽWii ๐Ÿณ๏ธโ€โšง๏ธ

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

Collapse
 
polterguy profile image
Thomas Hansen

Nested selectors is about time. I'm not sure about :has() since it makes the rendering engines more complex algorithmically, possibly degrading performance, or ...?

Collapse
 
darkwiiplayer profile image
๐’ŽWii ๐Ÿณ๏ธโ€โšง๏ธ

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.

Thread Thread
 
alohci profile image
Nicholas Stimpson • Edited

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.

Thread Thread
 
polterguy profile image
Thomas Hansen

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 ...

Thread Thread
 
darkwiiplayer profile image
๐’ŽWii ๐Ÿณ๏ธโ€โšง๏ธ

It's super easy:

  • list all your selectors with :has() somewhere in them
  • keep track of all elements that match the rest of the selector
  • follow the selector up to whatever ancestor (or descendant) the :has() applies to
  • keep track of these elements and only re-compute styles for changes inside them
  • spend another three to four decades fixing the countless bugs in your implementation, and the bugs you create by fixing those bugs, and the bugs resulting from optimisations of your previous bugfixes...

/s

Collapse
 
afif profile image
Temani Afif

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:

  • The houdini project where you and me can extend the CSS language with new feature (houdini.how/about/)
  • Cascade Layers that bring another level of flexibility related to CSS selectors: css-tricks.com/css-cascade-layers/
  • CSS variables, calc(), clamp(), etc. They are quite old but still not used a lot

And many more

Collapse
 
alohci profile image
Nicholas Stimpson • Edited

One thing I read recently that amazed me:

Set the left margin to be 1/10 of the widow[sic] width, but always more than 2em and less than 20em:

html : margin.left = 2em < WIDTH/10 < 20em

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.

Collapse
 
darkwiiplayer profile image
๐’ŽWii ๐Ÿณ๏ธโ€โšง๏ธ

calc() combined with var() and @property can be used to build amazing things without any need for pre-processors.

Collapse
 
auroratide profile image
Timothy Foster • Edited

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.

Collapse
 
darkwiiplayer profile image
๐’ŽWii ๐Ÿณ๏ธโ€โšง๏ธ

Old-school CSS was very much about compiling esoteric idioms for simple design concepts into actual designs (float et 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.

Collapse
 
auroratide profile image
Timothy Foster • Edited

Yep, exactly! Another example I thought of is aspect-ratio which 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.

Thread Thread
 
darkwiiplayer profile image
๐’ŽWii ๐Ÿณ๏ธโ€โšง๏ธ

Yes, a content-overlap property would be pretty nice.

Collapse
 
fjones profile image
FJones

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.

Collapse
 
leob profile image
leob

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!

Collapse
 
iamschulz profile image
Daniel Schulz

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.

Collapse
 
alaindet profile image
Alain D'Ettorre
  • SASS will be fully integrated into CSS (nesting, more functions etc)
  • There will be an easier way to style web components
  • Maybe people will re-discover that naming classes the right way then style them is better than drowning HTML and SASS with utility-only classes, who knows
Collapse
 
liviufromendtest profile image
Liviu Lupei

Junior Developer mentioning Tailwind CSS in 3, 2, 1 ...

Collapse
 
moopet profile image
Ben Sinclair

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.

Collapse
 
racheal profile image
Racheal Walker

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.

Collapse
 
sakethkowtha profile image
sakethk • Edited

I feel in future CSS may come up with css components similar to styled-components. We can maintain UI logic and functional logic separate.

Collapse
 
jaeming profile image
jaeming

Exactly. I'm working on a design system with the UX where I work and separating design logic from business logic has a huge appeal in building the component library. It also makes extending/overriding components easy and yet explicit.

Collapse
 
sakethkowtha profile image
sakethk

Awsome @jaeming good to here. Let me know once it come to mature state i will try it.

Collapse
 
sherrydays profile image
Sherry Day

It's still hard to test styles in an effective way. I'd like that to be an evolution.

Collapse
 
po0q profile image
pO0q ๐Ÿฆ„ • Edited

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.

Collapse
 
saptakbhoumik profile image
SaptakBhoumik

Maybe in the future sass will replace css and browsers will support it out of the box

Collapse
 
darkwiiplayer profile image
๐’ŽWii ๐Ÿณ๏ธโ€โšง๏ธ

On that day, I would abandon the web.

Collapse
 
saptakbhoumik profile image
SaptakBhoumik

Why tho

Collapse
 
vickalchev profile image
Vic

I'm surprised to see only one mention of utility libraries like Tailwind. I don't think such libraries are the only way forward but it's interesting to observe how they try to solve existing programs with CSS.

I'd like to see more logic introduced to CSS. We already have that with pseudo-classes but those are pre-written. What if we could create our own logic just like in any other programming languages?

Collapse
 
leob profile image
leob

Compared to styling/layout mechanisms used e.g. in Android or iOS, you can argue that CSS often feels somewhat "low level" and unintuitive, which can largely be attributed to its origins (it was not originally designed with application development in mind) ... maybe this is totally unrealistic, but if you view CSS as "the assembly language of layout/styling" (I came across this notion in one of the other comments), then I could imagine that someday someone might invent a new "higher level" layout/styling language, which generates CSS under the hood.

Collapse
 
jaeming profile image
jaeming • Edited

I haven't heard methodologies like BEM and SMACSS mentioned in years. I get the appeal of Tailwind as I like using utility classes in bootstrap. Having stuff like preset padding/margin values is good for consistency. Anyone that has experience with design tokens would probably appreciate Tailwind to a certain extent. But I don't like bloating my HTML with scores of combined classes personally. CSS-in-JS is a big movement that a lot of people are adapting. I'm interested to see in what ways it could impact the way people write and use css in any case.

Collapse
 
fjones profile image
FJones

The quick rise and fall of BEM in particular is fascinating. I'm not sure what killed it. CSS-in-JS? Preprocessing so heavy it made no sense to structure things that way anymore? Frameworks that just broke through with no adherence to BEM? It's an odd one.

Collapse
 
mnussbaumer profile image
Micael Nussbaumer

Personally I'm not a fan of css-in-js or utility based approaches to styling, for different reasons. I think some amount of utility classes for styling is always needed and useful, but basing entire layouts on classes doesn't lead to dry nor re-usable styling. I think pre-processors are - still - somewhat essential though, to give you a programmatic of generating those necessary utility classes in a clean way (generating variations for buttons/colors/etc).

In terms of CSS although it has improved a lot, I think vertical alignment in some situations is still not solved, flexbox does solve almost everything else.

One thing I miss is when text needs to fit a certain rectangle (single or multi-line) I would like to be able to specify that "no matter how many characters use the biggest font-size up to X that makes this text fit into this rectangle" and it would automatically set the font-size to that - I would be ok if verylongstringsthatdonthappennaturally would be botched or illegible but that the common case would just be solved by the browser layout engine.

On the same vein, but probably not a common use case, would be neat to be able to specify flex elements and say, these elements have this height and width, start with that, if the total elements don't fit with those dimensions, make them smaller proportionally (keeping their original ratio) up to the minimum of X. If they still don't fit, then make the container overflow.

Collapse
Collapse
 
molydoly profile image
Molydoly

HTML and CSS are relatively 'old' coding languages. However, they are still highly relevant for coders in 2022. Knowledge of HTML and CSS not only helps professional programmers, but also helps individuals in a variety of professions by giving them basic web page development knowledge.

Collapse
 
blicat profile image
float • Edited

HTML and CSS are two computer languages that are considered to be "old." They are, nonetheless, still quite important for coders in 2022. HTML and CSS knowledge benefits not just experienced programmers, but also individuals in a range of occupations by providing them with fundamental web page building skills.

Collapse
 
murdercode profile image
Stefano Novelli

I dream a world where the hamburger menus are all made in CSS

Collapse
 
lil5 profile image
Lucian I. Last

But you can already make hamburger menus in pure css, using the checkbox input element

Collapse
 
murdercode profile image
Stefano Novelli

I know, that's why I said "all".

Collapse
 
darkwiiplayer profile image
๐’ŽWii ๐Ÿณ๏ธโ€โšง๏ธ

With Layers and Scope coming to CSS (hopefully soon), the only thing I feel is missing would be CSS Nesting.

Collapse
 
alohci profile image
Nicholas Stimpson

I wouldn't be surprised if CSS Nesting didn't make it to interoperable implementation before Scope. I think there's far more open questions and implementation complexity to Scope than to Nesting.

Collapse
 
darkwiiplayer profile image
๐’ŽWii ๐Ÿณ๏ธโ€โšง๏ธ

Yes; nesting is really just syntax sugar (as underlined by the fact that many preprocessors have this feature without any hacks to make it work), so it could be implemented relatively quickly.

Collapse
 
spiderpig86 profile image
Stanley Lim

Until CSS adopts the utility and feature-set of Sass, it will remain a primitive and repetitive way to style anything.

Collapse
 
blindfish3 profile image
Ben Calder

Hopefully people actually bothering to learn it properly; instead of relying on the CSS equivalent of JQuery :D

Collapse
 
nikhilroy2 profile image
Nikhil Chandra Roy

For some situation, we have to rely svg, canvas but if css new features give us a way to make something like wave effect, clip-path (a better way) it can help us a lot.

Collapse
 
adam_cyclones profile image
Adam Crockett ๐ŸŒ€

Skewmorphism flat and glass material then Skewmorphism

Collapse
 
itachiuchiha profile image
Itachi Uchiha

A spacecraft can be run with CSS and people can write an OS using CSS :P

Collapse
 
jeremybrett profile image
JeremyBrett