 Hello and welcome back to the CSS Podcast, where we break down CSS properties and concepts to bring you the best bits and pieces of what's happening on the web platform. There's so much going on right now, and it's definitely one of the most exciting times I can remember in my career for UI developers. So we want to keep you in the loop about all of these changes, and especially the ones you can use in browsers now. So today, we're talking about one of the biggest landings happening in responsive design space, and that is container queries. Container queries. Container queries. If you haven't heard about it, it's just fun to say too. If you haven't heard about container queries before, no worries. We're going to go over what they are, how to use them, and talk about what you can and can't do and what browsers today. So, Yuna, how would you describe to someone what a container query is? Good question. And it's kind of fine to describe something so visual in a podcast format, but let me paint you a picture. If you've built anything in the past 10 years, it's likely that you've had to think about how it would adapt to different screen sizes. You want your website to look good on both mobile and desktop and whatever is next, and you don't want to create a separate m.site for the different versions for the mobile site. So what do we use for that? Media queries. Exactly. You likely used a media query to set up some logic, which adjusts components styles at different screen sizes. And you might go from a single column layout to a two-column layout when the component has more screen real estate to take up. Oh, yeah, we had an episode on page media queries, episode 32. Yeah, good call. The problem is, using media queries, we only have access to the page's global viewport information, not the information of where the component appears. And in today's framework and component-based UI design systems, we're usually building reusable components that get placed on multiple pages and in multiple environments. With container queries, we can apply more granular logic to enable these components to own their responsive styles. Nice, yes. You might want a card component to have a single column portrait type layout if it's in a sidebar. But even though your user is looking at it from a really wide viewport, with container queries, you can actually write this logic and attach it to your target element. So you don't have to worry about where it lives in the UI and what the rest of the page looks like. When combined with flexible properties like grid and flexbox, there's even more cool things you can do. And you can write really robust, intrinsic design systems. It's a new entry point for responsive design. Nice, you have so many cool phrases to save our container queries. All right, so to use container queries, we first need to set containment on the parent element. We also have an episode all about containment. Now it's episode 43. This is like an episode just pointing you to other episodes. I know, because we've made so many at this point that we've covered most of CSS. This is true. And so now that's why this season we're talking about the new stuff. That's true, too. And there is. And there's still so much. Yeah, we're going to have a big season, so be excited, everyone. And for more really catchy phrases. OK, so we have an episode on containment as episode 43. And you can do this by using the new container type property and setting it. So what we meant by you can do this is you can create a container. And you can do this by setting it to size, style, or state. And this is the container type property. So there are three broader types of containment and they correspond to types of queries. Currently, browsers have only implemented size queries. But in the future, you may be able to query a parent's style and its state. So size queries can be broken down into inline size, like width and block size, like height, which would query the elements inline logical axis, right? Just so I could cover its horizontal and a Latin language or block logical axis, which is vertical and Latin languages. So to sum up, you can write container-type colon inline-size on a parent element whose children you want to style with container queries. And it'll look for the inline size horizontal space in this case. Yeah, so then you can set the type, but you can also name that parent container using the container name property. My daddy gave me a name. You could call it like sidebar or card container. Container name accepts a custom identifier string and it works in the same way that you would name a grid area if you've ever done that. So once you've given your container a name, you can then reference that name when writing a container query. So that might look like a container, card container, and then in parentheses, minwith 350px. And that might be the inline size that you're querying with the previous setup that you put with the container type. Giving your container a name is optional, but it's the best practice to make things a little bit more clear. And also named containers can really come in handy if you have an element with multiple parents that you're querying. So for example, I made a demo once where I had this responsive shopping card that shifted from icon only to like incrementally adding like detail and then text based on how much space it had. And it also lived inside of a product card container that I wanted to sometimes query that product card container. So I was applying different container styles with based on different container names to that product card, based on how I wanted to style it. And it was pretty critical that I had these different name containers. Otherwise I wouldn't know what it wanted me to look at. Right, yeah, like if you don't name it and it'll just kind of query to find the nearest container with containment on it, right? Yeah. So yeah, having a name makes it so that you don't have to guess which it's gonna traverse. You get to know and you get to point right to this container. Like, hey, this container that I said containment on, I would like to query you. If your width is above this, here's some special styles for your SVG. Yeah, exactly. All right, so you can write container name and container type in one line using the container shorthand property if you like shorthand, which I do. So this is also a new property that lands with container queries. So container accepts, so this is the new shorthand, it's just container. Just container. Just container accepts a container name and a container type all in one with name coming first. So you gotta give your container name to use the shorthand. But then after that, you can write for example, container colon card dash container space inline size to be a bit more concise with the name of the type. Yeah, so that's essentially just giving it a name and saying I wanna query it in the inline size direction. So all in one, nice and handy. It is like important to note that you have to have a name. You can't just write container inline size, which you used to be able to in early versions of the spec, but no longer. So update your demos if you had the old syntax. Can you use emojis container name? Probably. Probably. That sounds like fun. You can do that with grid names, so yeah. Cool. I don't see why not. Query than moji. Moji queries. So now that we've set up our parent container, we can actually query it. You can style any child element using at container and look for changes on its parent to apply the style specified in the at container rule. And this is where the similarities between media queries and container queries come into play. You write a container rule and then in curly braces, you put all the styling logic for the children inside of it. So for example, a non-named rule on an inline size container could look like at container, space, and parentheses, min dash width, colon, 500 pixels, close parentheses, open the curly brace, and then inside that, you'd have your styles like dot title and then font size to REM. You could change the font size with the width if you wanted to. For a name container, it would look like at container, space, card dash container, if that was the name, and then space, in parentheses, min width, colon, 350 px, close the parentheses, open the curly brace, and then inside of that, you would have your element and your styles like dot title, font size to REM. So yeah, you could do this two ways, but you'd use at container to write the entire container rule and you'd have a whole block of styles. Got it. Okay, so we've got like a three-part thing here. First, you have to establish a container. So something has to tell the browser, I will be queried and my width will be queried, for example, like my inline size, here's my name, maybe, and then some sort of container query gets authored that targets that container queries its width, just like it would be the browser viewport and then supplies a whole set of selectors and styles to be applied to that. Okay, and then your first one was just at container with no name, which means it's just gonna look to the nearest parent element that has containment on it, query that, versus the second example where you explicitly said, I wanna look at the card container container. Well, that was just fun to say. And then you can provide styles for the case where that's either over or below that width that you're at. Okay, awesome. Well, where's that leave us with? I guess some DevTools. Let's talk about some DevTools. If you're playing with container queries, there's also great DevTools in Chrome that you can try out. DevTools will show you a container badge in the DOM panel next to all the container parents, just like it does with like CSS grid parents. And if you click on that badge, it highlights all the children that query this parent. It's pretty sweet. And then in the elements panel, you can see all of your container declarations when they're active and fulfill the query's condition. When hovered over, the name turns into a link to the element in the elements panel and the styles pane displays the query property and its current value, which could be the width of the parent if querying inline size and like a Latin language. And finally, just like media queries, you can make adjustments and changes to any of the code in the styles pane, including the container declaration. And to top it off, there's a polyfill. If you want to use size-based container queries today, there's a polyfill on Google Chrome Labs. It works on Safari 13.4, Chrome 79, Edge 79, Samsung Internet 9.2, and Firefox 69+. So now let's talk about the future. The future. So I briefly hinted at this earlier, but querying size isn't the only thing you can do with container queries. In the future, you'll also be able to query a parent's CSS styles. That means you can query to test against any style of a target element's DOM tree and apply style containment on it. Also, the working group did resolve to make style containers the default. If you are wanting to look for an immediate parent, you're able to do that unlike with size containers where you have to set a containment type to size or inline size or block size. So yeah, why would you want to do this? So say you want to make text stand out inline. Like say you have an italicized quote in a paragraph, you might use an itag to make it italic. And that would work, it would be italic, but then what if that itag was inside of a block quote that also got styled with font style italic? No. You wouldn't be able to see the italic text of that itag. So maybe you'd want to give it a pink background instead to make it stand out in some other way. This kind of speaks to the problem that we have with global information when really in this case we need local information, local logical styles. So with style queries, you can query against a parent's styles to write more defensive CSS. And regardless of the type of element, if it's an itag or a span tag or a p tag or any other tag, style queries let you look at the specific style of any parent element to make styling decisions. You can also do this for CSS custom properties, which means that you can then abstract values to higher order variables like theme dark or spotlight true. You could query any parent element for a custom property state and apply a set of styles based on that. Wow. So it's pretty cool. And to use this type of query, you would wrap the styles in a style function so it would look like at container space style open parentheses. And then if it was variable, you could do like dash dash spotlight colon space true and then close your parentheses and then in the curly braces and you'd have the custom styles inside of the curly braces. So if you had a card that was the spotlight card and you applied any logic to set that to true or set that in the HTML around the DOM or whatever you did, you could have a whole set of styles based on that custom property value. I love that. It's awesome. Style queries are a part of the contain level three spec but they are not landing in the initial implementations of container queries in Chromium 105 and WebKit. But container queries will be stable for size queries in Chrome 105, Chromium 105 which is going to be August 30th. I think it goes stable or at the end of this month. But these are not supported yet with the container query polyfill either. So you can only do size queries for now. Style queries are the future. Yeah, I have a use case in my mind. I'm thinking about a lot. It's like you've got a background of your website and then you usually have like another layer on top that represents like some sort of surface. I always call them surface one and surface two. And it works out really nice when you only have like those things on that one surface. But as soon as I need to put a surface on a surface these style queries are going to be really clutched for me to be like, okay, what's the color? What's the style of this container I'm in? I need to be slightly darker than this or I need to be slightly lighter than this. And so the ability to know the background color of the context you're on is going to allow you to make some really, you know, smart decisions about your design and I was just really excited about it, super cool. Also a note about stability. By the time this podcast goes out it will be stable. We were coming at you from the past. Nice. And then we'll probably have a future episode where we're like, the future is now. You know, style queries are here. Okay, so then we also had state queries, right? Which you mentioned earlier as well. So that's this second part, future part too, is state queries. And this is thinking even further in the future because where the style queries are coming in the future the state queries will be even further. And these will be possible in CSS contain level four. And they're pretty early stages but they'd enable you to check if a parent is in a specific state, such as stuck, like is it sticky and stuck? Is it visible? Like is it even in the view? Is it in the DOM? Can people see it? Or is it snapped? And so you could be able to query the state of an element and then change a style based on those things. Super cool. Should be so handy. I feel like I keep wanting to like write all my CSS in container queries. Yeah, not as well. Yeah, so that is a wrap for today. This is definitely one of the most exciting features landing in web browsers this year. So definitely check it out if you have a chance and remember to polyfill it for production. If you have any CSS questions we'd love to answer them on the show. Please tweet us with the hashtag, CSS podcast. I'm at Yuna on Twitter. I'm at Argyle link and your question could help a lot of people. If you like the show, please give us a review on whatever podcast app you are using or share this podcast with a friend. Those reviews help other people discover our show and help us have more time to deliver better content for you. Thanks y'all, looking forward to your questions. Bye. Bye.