{"id":4888,"date":"2025-01-14T16:42:28","date_gmt":"2025-01-14T21:42:28","guid":{"rendered":"https:\/\/frontendmasters.com\/blog\/?p=4888"},"modified":"2025-01-16T14:42:47","modified_gmt":"2025-01-16T19:42:47","slug":"css-wishlist-for-2025","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/css-wishlist-for-2025\/","title":{"rendered":"CSS Wishlist for 2025"},"content":{"rendered":"\n

The new year is bringing out plenty of folks blogging about their CSS wishlists. It’s fun! I love thinking about the future of CSS capability, particularly now when CSS seems to be moving so fast. I’m going to make my own list by listing some of my own wishes, then linking up other people’s ideas who I agree with (from any year). <\/p>\n\n\n\n

Stuff That Doesn’t Exist Yet<\/h2>\n\n\n\n

Adam Argyle<\/a>: Pick Where to Stick<\/h3>\n\n\n\n

Layout with position: sticky;<\/code> doesn’t let you be as specific as you might want to be with what parent element it’s going to stick against.<\/em> Aside from other issues where it’s weirdly easy to break<\/em> the stickiness, I agree it would be nice to just say where you want it to stick:<\/p>\n\n\n\n

\n

For that all too common moment when you want to pick which element position sticky will respect. What if we could use container-name<\/code> or something<\/a> and reference it from position sticky by making it a function?<\/p>\n<\/blockquote>\n\n\n\n

Personally, I’d want the same thing for position: fixed;<\/code>. I think it’s a bit annoying that you can only use it relative to the viewport and not a specific parent container.<\/p>\n\n\n\n

Me<\/a>: Unlimited Pseudo Elements with More Placement Options<\/h3>\n\n\n\n

Why do we only get ::before<\/code> and ::after<\/code>? I’m sure there are historical discussions you could dig up, but whatever happened, that’s how it was specced out. Feels a little arbitrary to me, like if someone decided functions in JavaScript could only have two arguments. What if it matched the great API that is insertAdjacentHTML<\/code> and we had ::beforebegin<\/code>, ::afterbegin<\/code>, ::beforeend<\/code>, and ::afterend<\/code>? That would be nice. Even better, no particular limit to them, like ::afterbegin(n)<\/code> which would allow us to add as many of these as we like. After all, they help us keep non-content elements out of HTML, which is typically A Good Thing\u2122.<\/p>\n\n\n\n

Ryan Trimble<\/a>: Promoting Elements to the Top Layout without<\/em> Popover<\/h3>\n\n\n\n

A massive reason to use the popover<\/code> attribute to create native popovers is that you don’t have to fiddle with z-index<\/code> and stacking contexts and such. If it’s open, users will be able to see it, because it’s promoted to what’s called the “top layer”. This is an amazing feature! I can imagine how careful the specs need to be to prevent it from being just another thing that’s easy for authors to screw up, but I can also imagine opening up this superpower to more than the handful of things that happen to use it today.<\/p>\n\n\n\n

Me: An extend()<\/code> Function<\/h3>\n\n\n\n

The concept of “extend” (in my mind) comes from Sass<\/a>. It means: make this selector have the same styles as this other selector. Maybe it could remain an at-rule in CSS that looks like a function?<\/p>\n\n\n

\/* somewhere in any loaded CSS *\/<\/span>\n.special-title-style<\/span> {\n  paint-order<\/span>: stroke fill;\n  -webkit-text-stroke<\/span>: 6px<\/span> #b39ddb<\/span>;\n  text-shadow<\/span>: -1px<\/span> -1px<\/span> 0<\/span> white;\n}\n\n\/* somewhere else in CSS *\/<\/span>\n#matching<\/span> .what<\/span> .the<\/span> .CMS<\/span> [gave-me]<\/span> {\n  @extend(.special-title-style); \/* NOTE:<\/span> not real yet *\/<\/span>\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
This would be helpful when you have less control over the HTML. Like you both<\/em> don’t want to wrestle control over what the CMS is outputting (because that’s technical debt) and<\/em> you don’t want to bend your CSS system to the whims of the CMS either. <\/p>\n\n\n\n
Sass has @extend()<\/code> and it’s sometimes called an anti-pattern, but that’s largely because it can produce ultra-verbose CSS that you might not even be aware of, which would not be a problem in native CSS. <\/p>\n\n\n\n
Rachel Andrew<\/a>: Regions & Reading Flow<\/h3>\n\n\n\n
With grid and flexbox we were given the power to easily reflow and reorder<\/a> elements in ways that very much do not match whatever the current languages natural flow is (e.g. left to right and top to bottom). This can be an accessibility issue where the source order, and thus typically the tabbing order, doesn’t match the visual order, which can confuse people and\/or lead to awkward screen-jumping.<\/p>\n\n\n\n
There is a draft for reading-flow<\/code> that Rachel explains<\/a>:<\/p>\n\n\n\n
\n
The property aims to solve the issue where the source (and therefore tab) order of a page gets disconnected from layout when using CSS grid layout or flexbox. This is a problem I\u2019ve been talking and writing about for a long time<\/a>. As soon as I realized this problem existed when using grid, I felt as if we were giving people potential with one hand but then removing it with the other. I\u2019m very happy that we\u2019re now fixing that problem.<\/p>\n<\/blockquote>\n\n\n\n
Yes please. <\/p>\n\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n
The rule reading-flow: grid-rows<\/code> in this demo<\/a> would make assistive tech read how it looks<\/em> (4, 2, 3, 1) rather than what the source is (1, 2, 3, 4).<\/p>\n\n\n\n
At the risk of sounding lazy, I’d want to do html { reading-flow: make-it-all-correct; }<\/code> \u2014 that is \u2014 just not worry about moving around the order of things, make a browser heuristic in charge of making the tab ordering logical. <\/p>\n\n\n\n
Me: image-set()<\/code> with Container Size Breakpoints<\/h3>\n\n\n\n
I just ran across this the other day so I figured I’d put it on my list. I had a container where I wanted to swap out the background-image<\/code> at different container widths. Container queries can do this by writing a container queries that override the background-image<\/code>, but it occurs to me that we could do it in a more concise image-set()<\/a><\/code> declaration if that were to be allowed.<\/p>\n\n\n
.card<\/span> {\n  container<\/span>: card \/ inline-size;\n\n  .card-banner {\n    background-image<\/span>: image-set<\/span>(\n      \/* Not real... yet *\/\n      \"small.jpg\"<\/span> container(width < 500px<\/span>)\n      \"large.jpg\"<\/span> container<\/span>(width >= 500px<\/span>)\n    );\n  }\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Sarah Gebauer<\/a>: :local-link<\/code><\/h3>\n\n\n\n
\n
The pseudo-class :local-link<\/strong> is a selector which targets links that point to the same web site. At the moment it’s not supported by any browser.<\/p>\n<\/blockquote>\n\n\n\n
That would be cool. I wonder if people had easier access to style<\/em> same-website links differently easily, they would be less quick to target=\"_blank\"<\/code><\/a>, which I’m of the opinion you should only do in rare and specific circumstances.<\/p>\n\n\n\n
Roman Komarov<\/a>: Shrinkwrapping<\/h3>\n\n\n\n
\n
There is one old, yet unsolved, CSS problem: shrinking containers to fit the content when it automatically wraps.<\/p>\n<\/blockquote>\n\n\n\n
When an element wraps, the width becomes as wide as the container. But that feels\/looks silly sometimes when the new now-wrapped content doesn’t occupy all that space. <\/p>\n\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n
Me<\/a>: Be able to style the handle on resizeable elements<\/h3>\n\n\n\n
See those little line nuggets in the bottom right? I think they are ugly and I want to style them. <\/p>\n\n\n\n\t\t
\n\t\t\t