Our application works like a lego builder. Each element is a brick and each brick can be piled to generate a page. With this we will be able to encapsulate a lot of presentation code. No more need to understand the context were a brick is used. We will be able to simplify a lot of our code base. This is the CSS super power we were waiting for. Time to see if our users have a compatible browser.
That sounds like an exciting project! CSS is truly evolving into a superpower. According to CanIUse, container queries already have over 90% browser support, and hopefully, that will improve further!
Hey, thanks for the tips) My point would not be popular, however, when doing the next project, I always think that this is definitely not the place for experiments. As a result, apparently, I do stick with the well-recommended and tested way of doing things. And this is actually bad, this is what holds developers back because all new technologies are actually modifications of trivial and well-tested methods. Miss one and you'll miss all the next chain. I'm trying to say, that having them at least nearby, available on hand, is pretty good. So, thanks for the tips 😁
Thanks for sharing your thoughts! 😊 I totally get your point - most developers, including me, tend to stick with tested methods on production sites. But I always experiment with new ways in my personal projects. Once browser compatibility improves, I start using them everywhere. That way, I try to stay ahead of the curve and know exactly what can be done without any surprises. And having these new tools nearby, like you said, makes all the difference!
Great question! Container queries aren’t necessarily better than media queries - they’re designed for different scenarios. Media queries work for page-wide responsiveness, while container queries let components adapt based on their container’s size. They also fix issues like making components responsive in nested layouts without relying on the whole page's size. Perfect for modern, flexible designs!
All good, but these are unusable with component approach. What we need is container-type: size to be the default of all nodes + a @container() function and a :: parent selector so we could generate dynamically the rule. The problem is that this logic MUST ve defined on the node itself and not depend on the parent css declarations. Otherwise it's either unusable or u need to make an extra wrapper element in your component which is a bad practice
Thanks for the feedback! I might not be following everything exactly, but container-type size can disrupt the regular flow of the layout. As for container(), we might achieve a similar result with container-name, and we now have the 'has' pseudo-class, which can help with parent selection.
I definitely didn't know about container-length units; a new area to explore. My :root{ font-size:15px } @media(XXX) { :root{ font-size:13px } }, 12px, 11px... is too old)) 👴 Despite it works perfectly fine, yet))
Apart from the main topic, I like the subtle grid-lines background in body. I notice in codepen is done with CSS. Well-curated content overall!
Thanks again! I've been asked about those grid lines a couple of times, and they were expecting a quick explainer video 😊
Our application works like a lego builder. Each element is a brick and each brick can be piled to generate a page. With this we will be able to encapsulate a lot of presentation code. No more need to understand the context were a brick is used. We will be able to simplify a lot of our code base. This is the CSS super power we were waiting for. Time to see if our users have a compatible browser.
That sounds like an exciting project! CSS is truly evolving into a superpower. According to CanIUse, container queries already have over 90% browser support, and hopefully, that will improve further!
love these videos :)
Thank you, glad you like them!
Such good videos. Love it❤
Thank you! Appreciate your support.
Hey, thanks for the tips) My point would not be popular, however, when doing the next project, I always think that this is definitely not the place for experiments. As a result, apparently, I do stick with the well-recommended and tested way of doing things. And this is actually bad, this is what holds developers back because all new technologies are actually modifications of trivial and well-tested methods. Miss one and you'll miss all the next chain. I'm trying to say, that having them at least nearby, available on hand, is pretty good. So, thanks for the tips 😁
Thanks for sharing your thoughts! 😊 I totally get your point - most developers, including me, tend to stick with tested methods on production sites. But I always experiment with new ways in my personal projects. Once browser compatibility improves, I start using them everywhere. That way, I try to stay ahead of the curve and know exactly what can be done without any surprises. And having these new tools nearby, like you said, makes all the difference!
so is this better than media query and if not when should I use it?
Great question! Container queries aren’t necessarily better than media queries - they’re designed for different scenarios. Media queries work for page-wide responsiveness, while container queries let components adapt based on their container’s size. They also fix issues like making components responsive in nested layouts without relying on the whole page's size. Perfect for modern, flexible designs!
All good, but these are unusable with component approach.
What we need is container-type: size to be the default of all nodes + a @container() function and a :: parent selector so we could generate dynamically the rule.
The problem is that this logic MUST ve defined on the node itself and not depend on the parent css declarations. Otherwise it's either unusable or u need to make an extra wrapper element in your component which is a bad practice
Thanks for the feedback! I might not be following everything exactly, but container-type size can disrupt the regular flow of the layout. As for container(), we might achieve a similar result with container-name, and we now have the 'has' pseudo-class, which can help with parent selection.
I definitely didn't know about container-length units; a new area to explore. My :root{ font-size:15px } @media(XXX) { :root{ font-size:13px } }, 12px, 11px... is too old)) 👴 Despite it works perfectly fine, yet))
Container-length units are definitely something to explore! They open up more flexibility for responsive designs.