Philip Walton for Google responded to our question We’ve Got Container Queries Now, But Are We Actually Using Them? There are a variety of reasons why usage of them seems to be low, but certainly developers worried about browser support is still a factor. The biggest quoted concern is Safari 15, which is entirely reasonable.
Philip lays out a technique where you build a <responsive-container> Web Component which has a ResizeObserver that updates classes on itself you can use for fallback styles in browsers that don’t support @container.
It’s clever and efficient, but there is stuff I worry about:
- You can’t just update
@mediaqueries to@containerqueries with the same numbers, they measure very different things and will now break at different places. - Every component is going to have different breakpoints, and now you need to keep those breakpoints synced in both HTML and CSS.
- Dealing with that style duplication is tricky. I would think a lot of setups don’t have a processing setup that has mixin abilities.
Still, if this helps you build a better system you can get to production, godspeed.
Thanks for the feedback, Chris! By the way, I updated the post to clarify the concern you brought up in #1. I agree that they’re not the same thing, so I went into a bit more detail on how to move from one to the other.
For #2, I both do and don’t agree. While yes, it could certainly be the case that a bunch of components all have different “ideal” breakpoints. In practice, though, I don’t find it that limiting to stick to a fixed set. If needed, the fixed set could even contain lots of options for max flexibility, e.g.
bp300,bp400,bp500, etc. (And I updated the post to mention that too.)For #3, yep, 100%. I don’t normally use Sass, but I used it for this demo just because it had mixins that would make this easier. Lots of folks still do us Sass, but obviously lots also don’t…
🤘