Webmasters Gallery

2024 has been one of the greatest years for CSS: cross-document view transitions, scroll-driven animations, anchor positioning, animate to height: auto, and many others. It seems out of touch to ask, but what else do we want from CSS? Well, many things!

We put our heads together and came up with a few ideas… including several of yours.

Geoff’s wishlist

I’m of the mind that we already have a BUNCH of wonderful CSS goodies these days. We have so many wonderful — and new! — things that I’m still wrapping my head around many of them.

But! There’s always room for one more good thing, right? Or maybe room for four new things. If I could ask for any new CSS features, these are the ones I’d go for.

1. A conditional if() statement

It’s coming! Or it’s already here if you consider that the CSS Working Group (CSSWG) resolved to add an if() conditional to the CSS Values Module Level 5 specification. That’s a big step forward, even if it takes a year or two (or more?!) to get a formal definition and make its way into browsers.

My understanding about if() is that it’s a key component for achieving Container Style Queries, which is what I ultimately want from this. Being able to apply styles conditionally based on the styles of another element is the white whale of CSS, so to speak. We can already style an element based on what other elements it :has() so this would expand that magic to include conditional styles as well.

2. CSS mixins

This is more of a “nice-to-have” feature because I feel its squarely in CSS Preprocessor Territory and believe it’s nice to have some tooling for light abstractions, such as writing functions or mixins in CSS. But I certainly wouldn’t say “no” to having mixins baked right into CSS if someone was offering it to me. That might be the straw that breaks the CSS preprocessor back and allows me to write plain CSS 100% of the time because right now I tend to reach for Sass when I need a mixin or function.

I wrote up a bunch of notes about the mixins proposal and its initial draft in the specifications to give you an idea of why I’d want this feature.

3. // inline comments

Yes, please! It’s a minor developer convenience that brings CSS up to par with writing comments in other languages. I’m pretty sure that writing JavaScript comments in my CSS should be in my list of dumbest CSS mistakes (even if I didn’t put it in there).

4. font-size: fit

I just hate doing math, alright?! Sometimes I just want a word or short heading sized to the container it’s in. We can use things like clamp() for fluid typesetting, but again, that’s math I can’t be bothered with. You might think there’s a possible solution with Container Queries and using container query units for the font-size but that doesn’t work any better than viewport units.

Ryan’s wishlist

I’m just a simple, small-town CSS developer, and I’m quite satisfied with all the new features coming to browsers over the past few years, what more could I ask for?

5. Anchor positioning in more browsers!

I don’t need anymore convincing on CSS anchor positioning, I’m sold! After spending much of the month of November learning how it works, I went into December knowing I won’t really get to use it for a while.

As we close out 2024, only Chromium-based browsers have support, and fallbacks and progressive enhancements are not easy, unfortunately. There is a polyfill available (which is awesome), however, that does mean adding another chunk of JavaScript, contrasting what anchor positioning solves.

I’m patient though, I waited a long time for :has to come to browsers, which has been “newly available” in Baseline for a year now (can you believe it?).

6. Promoting elements to the #top-layer without popover?

I like anchor positioning, I like popovers, and they go really well together!

The neat thing with popovers is how they appear in the #top-layer, so you get to avoid stacking issues related to z-index. This is probably all most would need with it, but having some other way to move an element there would be interesting. Also, now that I know that the #top-layer exists, I want to do more with it — I want to know what’s up there. What’s really going on?

Well, I probably should have started at the spec. As it turns out, the CSS Position Layout Module Level 4 draft talks about the #top-layer, what it’s useful for, and ways to approach styling elements contained within it. Interestingly, the #top-layer is controlled by the user agent and seems to be a byproduct of the Fullscreen API.

Dialogs and popovers are the way to go for now but, optimistically speaking, these features existing might mean it’s possible to promote elements to the #top-layer in future ways. This very well may be a coyote/roadrunner-type situation, as I’m not quite sure what I’d do with it once I get it.

7. Adding a layer attribute to tags

Personally speaking, Cascade Layers have changed how I write CSS. One thing I think would be ace is if we could include a layer attribute on a tag. Imagine being able to include a CSS reset in your project like:

<link rel="stylesheet" href="https://cdn.com/some/reset.css" layer="reset">

Or, depending on the page visited, dynamically add parts of CSS, blended into your cascade layers:

<!-- 
Global styles with layers defined, such as:
 @layer reset, typography, components, utilities;
-->
<link rel="stylesheet" href="/styles/main.css"> 

<!-- Add only to pages using card components  -->
<link rel="stylesheet" href="/components/card.css" layer="components">

This feature was proposed over on the CSSWG’s repo, and like most things in life: it’s complicated.

Browsers are especially finicky with attributes they don’t know, plus definite concerns around handling fallbacks. The topic was also brought over to the W3C Technical Architecture Group (TAG) for discussion as well, so there’s still hope!

Juandi’s Wishlist

I must admit this, I wasn’t around when the web was wild and people had hit counters. In fact, I think I am pretty young compared to your average web connoisseur. While I do know how to make a layout using float (the first web course I picked up was pretty outdated), I didn’t have to suffer long before using things like Flexbox or CSS Grid and never grinded my teeth against IE and browser support.

So, the following wishes may seem like petty requests compared to the really necessary features the web needed in the past — or even some in the present. Regardless, here are my three petty requests I would wish to see in 2025:

8. Get the children count and index as an integer

This is one of those things that you swear it should already be possible with just CSS. The situation is the following: I find myself wanting to know the index of an element between its siblings or the total number of children. I can’t use the counter() function since sometimes I need an integer instead of a string. The current approach is either hardcoding an index on the HTML:

<ul>
  <li style="--index: 0">Milk</li>
  <li style="--index: 1">Eggs</li>
  <li style="--index: 2">Cheese</li>
</ul>

Or alternatively, write each index in CSS:

li:nth-child(1) { --index: 0; }
li:nth-child(2) { --index: 1; }
li:nth-child(3) { --index: 2; }

Either way, I always leave with the feeling that it should be easier to reference this number; the browser already has this info, it’s just a matter of exposing it to authors. It would make prettier and cleaner code for staggering animations, or simply changing the styles based on the total count.

Luckily, there is a already proposal in Working Draft for sibling-count() and sibling-index() functions. While the syntax may change, I do hope to hear more about them in 2025.

ul > li {
  background-color: hsl(sibling-count() 50% 50%);
}

ul > li {
  transition-delay: calc(sibling-index() * 500ms);
}

9. A way to balance flex-wrap

I’m stealing this one from Adam Argyle, but I do wish for a better way to balance flex-wrap layouts. When elements wrap one by one as their container shrinks, they either are left alone with empty space (which I don’t dislike) or grow to fill it (which hurts my soul):

I wish for a more native way of balancing wrapping elements:

It’s definitely annoying.

10. An easier way to read/research CSSWG discussions

I am a big fan of the CSSWG and everything they do, so I spent a lot of time reading their working drafts, GitHub issues, or notes about their meetings. However, as much as I love jumping from link to link in their GitHub, it can be hard to find all the related issues to a specific discussion.

I think this raises the barrier of entry to giving your opinion on some topics. If you want to participate in an issue, you should have the big picture of all the discussion (what has been said, why some things don’t work, others to consider, etc) but it’s usually scattered across several issues or meetings. While issues can be lengthy, that isn’t the problem (I love reading them), but rather not knowing part of a discussion existed somewhere in the first place.

So, while it isn’t directly a CSS wish, I wish there was an easier way to get the full picture of the discussion before jumping in.

What’s on your wishlist?

We asked! You answered! Here are a few choice selections from the crowd:

• Rotate direct background-images, like background-rotate: 180deg
• CSS random(), with params for range, spread, and type
• A CSS anchor position mode that allows targeting the mouse cursor, pointer, or touch point positions
• A string selector to query a certain word in a block of text and apply styling every time that word occurs
• A native .visually-hidden class.
• position: sticky with a :stuck pseudo

Wishing you a great 2025…

CSS-Tricks trajectory hasn’t been the most smooth these last years, so our biggest wish for 2025 is to keep writing and sparking discussions about the web. Happy 2025!

A CSS Wishlist for 2025 originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.