Container queries are always on the top of the list of requested improvements to CSS. The general sentiment is that if we had container queries, we wouldn’t write as many global media queries based on page size. That’s because we’re actually trying to control a more scoped container, and the only reason we use media queries for that now is because it’s the best tool we have in CSS. I absolutely believe that.
There is another sentiment that goes around once in a while that goes something like: “you developers think you need container queries but you really don’t.” I am not a fan of that. It seems terribly obvious that we would do good things with them if they were available, not the least of which is writing cleaner, portable, understandable code. Everyone seems to agree that building UIs from components is the way to go these days which makes the need for container queries all the more obvious.
It’s wonderful that there are modern JavaScript ideas that help us do use them today — but that doesn’t mean the technology needs to stay there. It makes way more sense in CSS.
Here’s my late 2019 thought dump on the subject:
- Philip Walton’s “Responsive Components: a Solution to the Container Queries Problem” is a great look at using JavaScript’s
ResizeObserveras one way to solve the issue today. It performs great and works anywhere. The demo site is the best one out there because it highlights the need for responsive components (although there are other documented use cases as well). Philip even says a pure CSS solution would be more ideal. - CSS nesting got a little round of enthusiasm about a year ago. The conversation makes it seem like nesting is plausible. I’m in favor of this as a long-time fan of sensible Sass nesting. It makes me wonder if the syntax for container queries could leverage the same sort of thing. Maybe nested queries are scoped to the parent selector? Or you prefix the media statement with an ampersand as the current spec does with descendant selectors?
- Other proposed syntaxes generally involve some use of the colon, like
.container:media(max-width: 400px) { }. I like that, too. Single-colon selectors (pseduo selectors) are philosophically “select the element under these conditions” — like:hover,:nth-child, etc. — so a media scope makes sense. - I don’t think syntax is the biggest enemy of this feature; it’s the performance of how it is implemented. Last I understood, it’s not even performance as much as it mucks with the entire rendering flow of how browsers work. That seems like a massive hurdle. I still don’t wanna forget about it. There is lots of innovation happening on the web and, just because it’s not clear how to implement it today, that doesn’t mean someone won’t figure out a practical path forward tomorrow.
I think for this we’ll see people using CSS with JavaScript-based Observers like Resize Observer, and also Mutation Observer and Intersection Observer together in a synergetic way that lets you naturally define breakpoints as custom properties of elements, and have JavaScript code that observes the page and allows the elements to be targeted in its different breakpoint states.
There’s already a specific demo I have in mind as I’m writing this that’s waiting for the right time to be shown to the world, but I don’t think any pieces are missing if we want to use CSS and JavaScript together in this way. ‘Element Queries’ and ‘Container Queries’ may not be a CSS feature, they may be a CSS technique or a certain way of using CSS and JavaScript together, naturally. Keep an eye out for how to use JS-based Observers and CSS together like friends!
If a given pattern is repeated often enough in the real world, it eventually gets added natively. Web components, CSS variables, JavaScript “classes”, querySelector, even rounded corners were all nativized because “shoehorning” them was so common; usually through some other technology.
Container queries are a bit of an odd case because the end solution has such high consensus that few projects want to implement a polyfil. This lack of adoption is misconstrued as lack of interest to a casual observer.
We as a community need to embrace a JS solution first. When that becomes common enough to be considered a pseudo-standard, we’ll get our CSS solution.
Very well put. I feel like there needs to be some sort of unofficial but tightly-knit dev community that work on various libraries and polyfills for unofficial features that work well enough to be put into production, but with the idea being that eventually, if enough people use them, browser vendors will take note and implement a native version. There’s no reason to sit around waiting for them. This polyfill community could also have very lax rules for what’s included: the ringer that these features would go through is whether they ever became popular, so it’s more democratic and less bureaucratic.
I literally talk about this once a week, either with my teammates when we’re frustrated over working with an outdated grid system, or with designers that are frustrated that we’re not very good at implementing their beautiful grid system.
This is absolutely my number one desired CSS feature, above subgrid or whatever else they are cooking up. Elements that can visually adapt to the size of the space they’re placed within? Sign me up.
I would love a way to tell the powers that be what we want most. If we can catalog the ‘almost perfect’ bits of CSS and prioritize them, maybe we can get more light shined on them? It feels like these things aren’t being designed by people who actually use them. Some of us write a lot of CSS – and if we could have some entry point to stress test these decisions – we might come up with some helpful edge cases.
Sounds like you’re unaware of the CSS Working Group. Check out Rachel Andrew’s article then get involved :)
https://rachelandrew.co.uk/archives/2019/05/07/getting-involved-with-the-web-platform/
The working group’s Github can be found here:
https://github.com/w3c/csswg-drafts/issues