Container queries are so powerful, they really do what media queries can't do and I like that they can scope a css declaration to a specific component without having to worry about it affecting your whole UI, love it! can't wait for browser support
The “Add to cart” button here is a perfect example of the power of this abstraction and why it’s so useful to allow elements (or components) to only be concerned with the size of their container instead of only be able to use the full viewport. It’s a _huge_ improvement and I’m excited to see that browser support is improving on this every day.
On 11:30 why did she specified the same container-name for .cart-button too, but without container or container-type? And why do we need it, if we still can specify the styles for .cart-button within @container query section and it will be applied?
Can it trigger some infinite loop if I write some bad css. Is it possible that when a container break-point is hit its child changes in such a way that they in turn changes the size of a container? I write, when container max-width 200px { .child-div { width: 400px } } when div max-width: 400px { .child-div { width: 200px } }
@@UnaKravets yes this is true, I found out that the examples worked after adding the size function. Just to be clear, when you say reverted, do you mean it’s no longer in use? Because it still works for me.
I tried the new Container Queries in Canary with the experimental flag set to enabled but the demos are still not working like they did in the video... I have Canary Version 98.0.4750.0. Anyone know what may be the problem?
There was a (very recent) spec change to prepend with the size() function, i.e. @container size(min-width: ...) {} There's still discussion about if size() is required or both syntaxes (the function and the inital, similar to media queries) will be supported
@@UnaKravets Thanks for the quick follow up Una! I thought maybe I was losing my mind. Let me see if I can get them to work without the size() function.
I hope there's eventually going to be a polyfill for container queries that compiles at build time, ahead of time. Parsing and transforming CSS on the client side should never be necessary.
I don’t think that’s possible. Because of responsiveness happening at run-time, the only way to get the container element’s size is by querying the DOM with JS.
Of course, JS will be necessary. What I'd like is a solution that takes CSS that contains container queries and at build time from that generates css that contains classes like .my-element:where(.WidthHas500px) {...} and JS that contains Resize observers that then toggle these classes. That should improve performance and runtime bundle sizes over doing all of that, including parsing the CSS, at runtime. Of course it's a bad solution compared to having the browser implement it.
What is the capacity of container queries to keep the container flexible? Possible the answer would work in other industries as well😎 (in light and dark mode 👁️🗨️)
Container queries are so powerful, they really do what media queries can't do and I like that they can scope a css declaration to a specific component without having to worry about it affecting your whole UI, love it! can't wait for browser support
This is so cool. It makes web components so much more re-usable, dynamic, and natural.
😗 There's a new Chrome Dev Video
😯 Una's in it!
😲 It's about container queries!!
😵 container query based unit values!!!
The “Add to cart” button here is a perfect example of the power of this abstraction and why it’s so useful to allow elements (or components) to only be concerned with the size of their container instead of only be able to use the full viewport. It’s a _huge_ improvement and I’m excited to see that browser support is improving on this every day.
Truly next level. Thanks to all involved in this project.
Can't wait to use it! So excited!
I have waited so many years for this
Awesome how container queries changed the web development, I love so much!! 😍
Amazing feature, makes developers life easy.
You have become the queen of CSS!
First time on channel, good topics. Looking forward for more...
Thank you. That was pretty informative.
Looking forward for them to become stable on major browsers
Amazing! Thank you, Una 💖
On 11:30 why did she specified the same container-name for .cart-button too, but without container or container-type? And why do we need it, if we still can specify the styles for .cart-button within @container query section and it will be applied?
so excited about this feature!
Can it trigger some infinite loop if I write some bad css.
Is it possible that when a container break-point is hit its child changes in such a way that they in turn changes the size of a container?
I write, when container max-width 200px { .child-div { width: 400px } }
when div max-width: 400px { .child-div { width: 200px } }
Is there a way to clamp the minimum size for a container? Would clamp() or min() be a good solution?
Yep! You can clamp the parent! Either with min-width/max-width or width: clamp(). We do this on the former on the designcember site
Ok, What I understood... Is a CSS Component (UI).. right??
This is really amazing!
Yes
Ok
Hi, this was an awesome video. I tried checking out the examples on canary, but they don't seem to be working, what could be the problem?
There was a spec change to add a size() function requirement that has since been reverted
@@UnaKravets yes this is true, I found out that the examples worked after adding the size function. Just to be clear, when you say reverted, do you mean it’s no longer in use? Because it still works for me.
I tried the new Container Queries in Canary with the experimental flag set to enabled but the demos are still not working like they did in the video... I have Canary Version 98.0.4750.0. Anyone know what may be the problem?
There was a (very recent) spec change to prepend with the size() function, i.e. @container size(min-width: ...) {}
There's still discussion about if size() is required or both syntaxes (the function and the inital, similar to media queries) will be supported
@@UnaKravets Thanks for the quick follow up Una! I thought maybe I was losing my mind. Let me see if I can get them to work without the size() function.
@@RickBeacham This change has been reverted by the way(!) not in Canary yet
Is container query ready to use
You can use it with the polyfill: github.com/GoogleChromeLabs/container-query-polyfill
good info maam
amazing!
Can anyone provide a link to the CQ polyfill?
github.com/GoogleChromeLabs/container-query-polyfill
I hope there's eventually going to be a polyfill for container queries that compiles at build time, ahead of time.
Parsing and transforming CSS on the client side should never be necessary.
I don’t think that’s possible. Because of responsiveness happening at run-time, the only way to get the container element’s size is by querying the DOM with JS.
Of course, JS will be necessary.
What I'd like is a solution that takes CSS that contains container queries and at build time from that generates css that contains classes like .my-element:where(.WidthHas500px) {...} and JS that contains Resize observers that then toggle these classes.
That should improve performance and runtime bundle sizes over doing all of that, including parsing the CSS, at runtime. Of course it's a bad solution compared to having the browser implement it.
Why wasen't this implemented years ago?
What is the capacity of container queries to keep the container flexible? Possible the answer would work in other industries as well😎 (in light and dark mode 👁️🗨️)
🤯
Music please!
❤️
C'mon when is it going live?!
We have been waiting for ages...
If you want adoption make it available!!
No win delta
Obvious in hindsight!
Ch®️me
i wish these videos would get straight to the point and not waste our precious dev time
Does it help with CLS?