The #CSSWG just resolved to allow `var()` references in #CSS container queries:
```css
@container (inline-size > var(--small)) {
.card { padding: 2em; }
}
```
The custom property is resolved on the container – so we're querying if the computed value of `--small` on our container:
1. is valid in context (a `<length>` value), and
2. is less-than the container `inline-size`
It's not "custom media queries" feature, but it is Damn Close™️ – and maybe more powerful. I'm excited to play with it! 🥳
The `var()` reference can only be used for the value, not for the "feature" (`inline-size`, `orientation`, etc) or the entire query. We need to know what feature we are querying in order to find a container, so there's nothing to resolve against at that point. These will Not Work:
```css
.container {
--medium: (inline-size > 30em);
--axis: inline-size;
}
@container var(--medium) { … }
@container (var(--axis) > 30em) { … }
```
For those, we would still need "custom media queries".
I think I accidentally framed this as a negative. This is not a failed attempt at custom media! That might also happen - and has its own limitations.
This doesn't just allow a static "naming" of reused queries, it actually means we can define contextual values that *change what a query means per container*. That's a way more powerful feature which can only work in container queries!
So much potential here that goes beyond static re-usable breakpoints.
@mia Maybe an example of dynamic variable would be having a `--column-width` variable, and so the container query would be testing if the container is at least 3 columns wide or similar. But the width of your default column could change based on the media query or higher-up containers.
(If it's just a constant, it would ideally be done with custom env() rather than var() but I guess we have to wait for that, too...)
@ollicle Yes! html can be a container, for everything! And I recommend it. :)
We couldn't make it the default because it could break some old sites: https://codepen.io/miriamsuzanne/pen/gOjwygB
But people shouldn't rely on that propagation behavior, anyway.
Container queries on html have several advantages over media queries. In addition to var(), relative units in the query (like ems) are also be resolved on the container. No more "browser default em" calculations in queries!
@mia ooh, this is big!
Also small, and all the other sizes!
@mia I have been thinking about the reason why ppl decide to use `var()` to call custom properties... surprisingly, I still have no idea why.
Last time I check, fallback arg (2nd one) doesn't seem useful. And if fallback is really needed, just do like this `--css-var(fallback)`. Why we have to go all the way with vsr function?
@ngdangtu Fallback is absolutely useful:
- https://css-tricks.com/using-custom-property-stacks-to-tame-the-cascade/
- https://www.smashingmagazine.com/2019/07/css-custom-properties-cascade/
Sure, there could have been various ways to define a syntax for that - and I wasn't on the WG when this was discussed - but i expect
function(--dashed-ident, fallback)
is more clear, and invents less new syntax than
--dashed-ident-as-function(fallback)
Which is good, because now there is a proposal for more powerful custom functions using:
--dashed-ident(custom, args)
Eric Bailey
Mia (web luddite)
Amelia Bellamy-Royds
Morten Rand-Hendriksen
Ollie Boermans
Alex Russell
Ethan Marcotte
David Roessli
Đăng Tú