Container queries is a big deal in my opinion! This has always been an obstacle for designing responsive components - they only respond to the size of the screen so designing them for use in different places in your app is difficult.

But the implementation they’ve chosen with named containers is not my favorite. I’d prefer one that is simply based on the parent component or the closest component with a container attribute set; this would work better alongside tools like Tailwind and CSS-in-JS.

Edit: Nvm after reading more, it looks like the container name is optional and the default behavior is what I described - excellent!

Container queries allow devs to step away from the classic small, medium, large breakpoints for screen sizes and consider the best look for a certain component at different widths. This is much better because a component on screen can be affected by many different parent element’s breakpoints, so it’s hard to define when a screen size should affect a component. With containers, it’s very clear.

Yeah container queries are what I'm most excited about looking at this list. I was pretty bummed out to see they're only supported on 63.75% of browsers, and notably missing on most mobile browsers, where they'd be most useful.

10 years ago people said the same about the CSS3 changes.

I find most of this useless/overcomplicated. Who needs rounded corners? I like my png slicing. And what are box shadows anyway? There's nothing flexbox can do that I can't achieve with tables. Transitions are bad, transparency is for Apple fanbois, animations the devil's farts, and don't get me started on media queries. Phones should remain Nokia bricks.

This isn't even a straw man. Further down we're still having the tables vs CSS debate. I'm so happy we got all of the above and more and can't wait to see what's next.

> 10 years ago people said the same about the CSS3 changes

In OP's defense, I still say those things about the CSS3 changes.

Good for you. The rest of us will be using these new features to make great websites with far less wasted time and effort than before.

Exactly. Thank you for saying this. The curmudgeonliness on HN is ridiculous.

I can only remember that we applauded CSS3. Rounded corners and shadows were crucial to implement the design of the day. Animations and transitions were lovely. It was an exiting time to make stuff.

I recently implemented layers on my site https://daniel.do/ and honestly found it really helpful in terms of explicitly organizing specificity.

It also gives you a much clearer idea of where in your styling stack something is coming from.

> Container queries

Have you ever built a piece of functionality that goes on pages you don't control? For instance, I built software that displayed a map on people's pages. but I don't know the width of the map itself. They could be displaying it on the full width of their page or in a container. Media queries don't work in this scenario. Making the map correctly responsive forced me to use JavaScript to get the element's width.

The other solution people have for this is iframes, which suck too.

Just because you don't have a need for something doesn't mean nobody does.

I’m building a CMS and container queries will make the components I build sooo much better.

:has() is my most anticipated as well. it has the biggest potential to not only simplify our html (e.g., divitis) but also remove the need for js compensations in many content-oriented sites. come on firefox, let's get :has() across the finish line!

container queries are also neat, but still rely on having a wrapper container, which isn't ideal--why can't i style the component itself based on its own calculated height/width rather than having to involve a parent element?

i'm still waiting for chrome to implement subgrid, which will simplify any kind of card-type layout.

i also wish we had native "mixins" (@apply had this potential, but it was removed from the spec), so we could have a bundle of styles we could inject into different declarations as a group. then you could have different sets of styles in orthogonal groups (layout, spacing, border, text, inline) that you could apply in any combination. this is especially useful if you want to style a base html element a certain way and then also have a utility class with the same style later in the stylesheet (with maybe a slight tweak) that can be applied to more than just that type of element (like <div>s, <article>s, and <section>s).

edit: oh, and lch/oklch for more perceptually uniform and expanded colorspaces, combined with the new color functions (e.g., color-mix) is exciting too.

Inert is nothing new, you could already use pointer-events: none or tabindex or put a transparent div on top. This is just a better way to hint to the browser your intent, and for it to behave properly.

Does pointer events block focusing with a keyboard though?

Your comment reads like a lot of complaining by someone who doesn’t do a whole lot of CSS.

You’re complaining about the mere availability of color functions, that alone kills the rest of the comment.

> [re: layers] If you keep the cascade small and clean, you'll most likely not need that.

Many of us are not in that state due to piles of tech debt. One of my work projects is modernizing a 20ish year old, 300 page php app, and the css tech debt is awful. We're all looking forward to layers for some sanity.

(strong agree on your other points)

Inert is needed for <dialog>