Miriam Suzanne
===

[00:00:00] Hello, and welcome to PodRocket. I'm Noel, and rejoining us today is Marion Suzanne activist, artist, teacher, web developer, co creator of Oddbird let's see, invited expert at the W3C CSS Working Group, and SAS 4 contributor. Did I get all that right, Miriam? Yeah, I guess so. That sounds like a bio that I wrote at some point.

It's good having a long list of titles sometimes. But Miriam's here today to talk to us about CSS containers. So welcome back to the show. Thanks for having me. It's good to be here. Of course. Yeah, it's always a pleasure talking. I think we've talked.

I think this is like your second, third time on the show. I know we've talked a couple times, maybe somebody else talked to you in the past. Yeah, something like that. Yeah, Yeah. It's always a pleasure. So let's just give us a kind of reestablish this. Can you give us a brief overview of Who you are, your background and why you care about CSS.

yeah, I studied theater and then I needed a job. And I had learned some graphic design for marketing our shows. So I got a graphic design job. [00:01:00] And then somebody asked if I knew anyone who could build a website. So I learned how to do that too. And got obsessed with CSS in a weird way.

Saw some weird CSS experiments back in the early 2000s got really into sort of the semantics of the language what it's trying to do. And I've been doing it ever since. And at some point I also started teaching it and then was invited to join the working group. So now I. Get to work on the language itself, which is a lot of fun.

Yeah, very cool. I feel as web devs, everyone touches CSS a lot, but I think that it is, it's one of those languages that like a lot of people use, but not as many, like a very small cohort of those people actually sit and think about the semantics of the language, as you said in a way that's a little bit unique to CSS.

I'm not sure if it's like. The declarative kind of nature, or maybe the just something about web people are often not people that care about what color things are like [00:02:00] something depth, but there's something there. So it's always cool to talk to people who are like, thinking about the language itself.

Yeah. So what I guess. Yeah, let's jump right in. You recently did a talk on containers, right? That's available. What, why do you think now's an important time to have? Containers in the purview of devs. Well, we were told for the last 15 years that container queries would never happen.

I told people that container queries would never happen. And they're here and they're available in every browser. And it's time to start using them. And honestly, at this point, I can't convince a conference to let me talk about anything else. This is what people want to hear about.

So great. I'll talk about it. Yeah. So in the talk, you asked the question, what do containers know? What does that mean? Well, so, that came partially from the fact that we all knew the basics of what we wanted from container [00:03:00] queries. We knew about media queries. We measure usually the width of the viewport.

And we knew it would be nice if we could measure also the width of an element on the page. And so that's where it started, right? And we built the container query syntax from that point. But as soon as we had started writing that specification, we realized Well, if we can ask questions of elements, what other questions might we want to ask?

And so it quickly expanded out to include a lot of other features in addition to just asking the size of a container. So, the talk is partially about that. What all else might we ask a container? what are some of the... More interesting one, like what other data is exposed, at this container layer.

Well, we're still a little bit exploring that hopefully there will be some more features coming but we're querying an actual element on the page that [00:04:00] has already been laid out. At the point where the query is resolved. So we should know things like its font size. We should know Various things about its box So the first thing that we added was style queries, which let you say Is this property on the container set to this value?

And right now and maybe forever, that only works on custom properties 'cause it's a little hard to do on the full set of standard properties that are already there, which is too bad. I think there's some interesting features that could happen there if we're ever able to do it. And at this point I no longer tell people it'll never happen.

Yeah, . So maybe someday there's some things to figure out about that, but already. In the spec and in Chromium browser, so, Chrome and Edge and a number of others, you can check the value of a custom property on the container and write [00:05:00] styles that respond to that. So you can use that somewhat like a mixin.

You could set a theme property to darker light and then have your styles respond to that or something else. And we're working on state queries. Can we ask is the container in a sticky positioning and is it currently stuck? So that's the one that browser engineers are working on to see if we can do it.

Yeah, it's a good example because I feel like. There's just a lot of practical use cases for that right away, right? It just seems like a nice quality of life thing without having to like figure out, the height of the browser and where the sticky element would get stuck. Yeah yeah, I think a lot of the times these.

It's hard to come up with like nice, concise use cases for these things. And it's easy to be like, Oh, well, you shouldn't be doing that anyway. And then it's until you're like, seven layers deep, you have this complex style web, like this complex like CSS files and all this stuff going on.

You're like, Oh, but now I need this one thing. It sure would be nice if I could just do this. The rest of [00:06:00] the code would be way cleaner. Yeah. So that's, cool to hear. , so as an example you're saying like query containers, see if it's like, Sticky in general,

is there the capacity to like, get into infinite loops now with container queries? If I can query a style and then apply a style, it's it's like, oh, I could break that. Has that been happening in the wild and what do we do about it? That's why container queries will never happen. Yeah exactly.

Because it's absurd to measure something and then change it. So the way we get around that is through containment. Basically, containment is designed around different phases of browser rendering. So, size containment happens during layout and paint containment happens during rendering.

There's these different containments where we can say everything inside of this box should be isolated at this stage of rendering. And we use size containment for the main size queries. We say to [00:07:00] avoid the infinite loop, or the potential for looping, we will lay out this box as though it has nothing in it, and then we know its size, and we can put things in it and measure them and we know the size of the container, so the things inside of it can respond to that which is losing a core feature of CSS, or of the web generally, which is this idea that The box can change the size of the contents, but the contents can also change the size of the box.

We have to turn off that loop to get this to work, which is an invasive thing to do. So you create containers explicitly where you need them, but it's also, it's particularly dangerous if you had to turn off both the height and width. Aspects because then your content has nowhere to go. And you're going to take that CSS is awesome meme and make it way worse.

Your box just collapses down to zero [00:08:00] and all of your content is overflowing. That's not what you want. So one of the big things that had to get solved in order for browsers to ship this was a way of saying only add size containment on the inline axis, the width usually. And let the height continue to grow and shrink with the content.

And that matches how we do layout most of the time, right? We don't set heights on things. We set widths on things, and then we let the height grow and shrink. So we came up with a way to do that. Not me personally. That was mostly browser engineers figuring out that part. And there are a few little places where the width of something, well, No, the other way, where the height of something can change its width like by triggering scroll bars or a few other situations where it can happen.

So yes, there are still a few potential [00:09:00] leaks in the containment. And the browsers have resolved those basically by plugging each hole. They just say. Okay, well, we'll lay it out as though there's no scroll bars, then we'll add a scroll bar, but you'll still get the, but if that means that we wouldn't have one, or they'll only move forward in the loop, and if it ever tries to move backwards, they'll just cut it off.

So, yeah, they've just plugged the few holes and made it work. Yeah, nice. , you know, my uh, Messy abstraction alarm is going off here because it's just like this seems like something that as a dev I wouldn't want to have to think about most of the time but I could I can see cases where all of a sudden I've got to there's some weird unexpected behavior starts occurring.

I've got to go in and figure out what's going on Is that I know is that a fear that you guys have or is have you seen this happening in the wild at all? I haven't what's so a lot of [00:10:00] the places where there's those edge cases are the places where there are already those edge cases. As scroll bars triggering or not triggering already you have to be careful about it.

Yeah. And this doesn't really add to the problem that I've seen. It's it's been there and we work around it and yeah, most of the situations, if you add inline size containment, because the places that we want to measure are often also places where we already are setting an explicit width, it mostly just works the way we expect and a lot of the edge cases you don't run into because.

They're not the main thing you're trying to do. Yeah. Yeah, cool. I guess so that kind of leads nicely to my next question of what, like, how do you think devs should then be thinking about containers and like the these kinds of abstractions? Like when is it the right time to start reaching for [00:11:00] container queries?

Anytime you have something that is getting its width from outside. So from outside can mean from its context or. From it, from you if you're setting the width to something explicit, a pixel value or an M value or whatever you can use them. In most cases, I would say use them freely figure out where they work, what you need to measure and respond to.

I've seen great demos of using them for overall layout. Yeah. Demos of using them for cards in a layout, demos for using them on buttons, on SVGs inside of those buttons. There's not a right level for where they belong in your code. And we haven't seen performance hit with as with most complex things, you could probably find a performance hit if you really pushed.[00:12:00] 

But that's how code works. But no, they're they're not something that you should be afraid of and they're not something that you should isolate to one place in your code but you should be aware that they turn off this powerful back and forth of information. And so, if you're aware of that, I think you can work around it.

Yeah. Is that kind of making, making the back and forth like more of a waterfall or waterfall? Is that the reason that there's no like default? Containers. That is exactly a big part of it. The, there's also an uncertainty of what to do at the root cause we do a lot of magic at the root of sometimes when we talk about the root element, the HTML element, we're talking about the element itself.

And sometimes we're actually pushing things off to the viewport, which is the box around it. Yeah. Yeah. Yeah. And. haven't totally solved how container queries should interact [00:13:00] with those two magical boxes. And so it wasn't reasonable to put a default container there. Yeah, I don't want to go too far down that mental rabbit hole.

That sounds like it could be a nightmare. You said there's no, there was no like right or wrong way to do it. Reach for them if it seems like it'd be a useful tool. But are there any best kind of best practices that you.

would recommend to keep, to make sure devs don't find themselves painting themselves into a corner, falling into a common trap. Yeah, there's a few. I would probably add a container near the root maybe on a main element or on your, on the main pieces of your layout. Say I'll put one on the header, on the sidebar, on the main content and on the footer there, I've got some root containers roughly.

And now everything I put inside of them will have a default container to fall back on. I think that's probably a pretty good pattern. I would stick mostly to inline size containers. [00:14:00] That's mostly what you're going to want to use. Occasionally the way to realize that you might want a size container instead of an inline size container.

So that's containing both axes, height and width. You might want that if you're adding overflow. Scroll or overflow auto because then generally you're setting a height on something or maybe you're taking the height from the viewport and using it. So, in an application layout where everything scrolls you have nested the sidebar scrolls and the main content scrolls and the pointer is always there, whatever.

Those are the situations where you might want size containment because you've set a height. The other thing I would say is. It's a good practice to name your containers. You can put names on them and then when you're doing a container query, you can say, look for the, look for one with this name.

And you can use that both to say I have layout containers and I have other sort of component containers. So we [00:15:00] have those two classes. Okay, I'll give them a layout name or a component name. And then you can also give them more specific names. You can say, All right. The one on my main content, that's my main container and a layout container.

So I'll give it both of those names. It's a good idea to have those names there because then when you are trying to be specific about referencing the size of something, you can put that in your code and make sure it's not fragile. Yeah, seems just less prone to someone coming in later and breaking something or something.

Adding a container somewhere else that surprises you and gives you the wrong answer. Yeah exactly. I feel it's the same subset of problems that like CSS has, right? Like, These are the good things to do in CSS, continue doing that. Yeah, which in my mind is, CSS is designed to try to understand what you mean and do something good with it.

So always say what you mean, and if you mean the main container, then say the main container. If you mean just [00:16:00] any old container that has an answer, great. Say that. Say what you mean. Yeah. Yeah, what an interesting little, yeah, nugget there. So I feel like that is intuitive to most devs, but it becomes tricky a little bit, like when...

When the rubber meets the road, as it were, it's just yeah, you end up getting lazy and you're just like, or slapping ID selectors on everything, right? It's like making everything explicit. Why do you think that is so hard to I don't know, get those, get that level of specificity right?

Yeah, well, I think in imperative programming, we have the sense that it doesn't matter how you get there as long as you get the same answer. So then from that perspective, 16 pixels and 1M can often be the same thing. And in CSS, that's not how it works. Each thing has a semantic meaning to it, an intent behind it.

Right. 1M means I'm trying to do something relative to a font size. 16 [00:17:00] pixels means I, I just always want this size on the screen no matter what. And with CSS, everything is contextual. So giving it that kind of information about. This is what I intend, please be smart about it. Yeah yeah.

It's different than just getting the answer. Yeah, I think that kind of leads to this feeling people have, like, where in CSS, I feel like this is a thing that's been happening more as CSS is becoming more powerful and we can do more with less.

But it's just like that idea that less is more a lot of the time. Huh. Because it's just just tell the browser what to do. But I feel like that's always been in the DNA of what CSS is trying to achieve, but it just hasn't been super practical a lot of the time. We just had to do tons and tons, but it's getting better.

Like we can do less and less. Do you think containers are like another kind of step in that journey, like letting us do more with less CSS? Or do you think this is, it's more of just a quality of life thing? Yeah, I mean, hopefully it lets us, [00:18:00] so I think we've had lots of these media queries that are sort of like, okay, at this viewport size, I now, I know, personally, because I punched the numbers into a calculator.

Yeah. I know that when the viewport gets to that size, this element has gotten to this size. And now I want to switch something. So, we're adding media queries that are not what we mean. They're like our clever calculation that gets at the right answer. And now we can take that and just say what we mean.

Which is just measure that container element. So hopefully, yeah, even if it's not less code, it's less magic numbers in our code. It's more just. Expressive. Yeah. Yeah let's looking at something in the future and being like, what the hell, where did this 2, 187 come from and, but right, [00:19:00] it actually says what it's trying to do.

Yeah definitely. So we've been dancing around a little bit and you mentioned, I think your example before of a much more rigid layout or something like there's an overflow scroll, like a nav bar or something that's like scrolling on the left and sticky and positioning the content on the right.

I think that a lot of people probably then immediately start thinking of terms of like grid and flex and how to lay these things out. How do containers interact with Like flex sizing. Yeah that's a an interesting problem because Container queries measure a container which is an element on the page Always an ancestor element So you're looking at a parent or farther up the DOM tree and you're measuring the size of its content box and that's not what you want in Flexbox and Grid.

You're not, you don't want to measure the parent. You want to measure the track. Yeah, the siblings, this. Yeah. Flexbox doesn't have a [00:20:00] term for that, but like that. You want to measure the space that this element actually has. Yeah. And so, unfortunately when using those, you have to put an element in that you can measure.

So, I refer to these as turtle components. They have to carry their container with them, right? So just a little extra wrapper div or whatever that can be the container for the item. And then you can measure that and change the things inside. So that's a little bit of extra markup, which is unfortunate, but it gives you that ability to measure an actual element.

Yeah, Yeah, the the gap needs bridged somewhere or else again, I think you just end up, it'd be kind of another manifestation of that problem we were talking about right at the beginning, right? I'm just like, you're expecting these things to be responsive in this direction, like of state flow, but they're not always, if you are measuring the size and then making changes based on the data that's coming out of the system.

Yeah. There was another. There was another [00:21:00] proposal that would have handled that differently that would have let you measure actual available size, but then the trade off on that one would have been you can only set things that wouldn't affect that size. So that seemed like an even harder trade off to make, even though it gives you somewhat more of the answer you want.

It then restricts what you can do with it too much. So yeah, maybe someday we'll have both. I don't know. Yeah, and I think that If that route had been the one that had been chosen, I think that would also be like even more unexpected behavior if you're like a dev and just going in and trying to do this, like, why is this attribute not doing anything, like in a really hard to Google way.

Yeah, suddenly you're memorizing lists of properties that are allowed. Yeah. Yeah. Yeah, maybe the browser can like. Tell you, I feel like a lot of the time that's how we learn as we go in and something's highlighted or crossed out in the dev tools, but yeah, like avoiding those unexpected cases cool.

Yeah.

So, so like I've hit the [00:22:00] limits on my container query knowledge. We've got a couple more questions. I just wanted to ask what are container query units. Yeah. Container query units are similar to viewport units. So in the same way we both have media queries that can respond to the size of the viewport.

We also have viewport width, viewport height, viewport inline, viewport min, viewport max. Those vmin, vmax, vw, vi. We have all those units. That just give us that size and we can do something with it. We can put it in a calc for setting our font sizes or something. We figured we'll want the same thing with containers.

So we added those. They're CQ instead of V. V for viewport, CQ for container query. We couldn't use C because CH already exists. And we couldn't use Q because Q already exists. [00:23:00] But CQ, So it's the same set of units, but looking at the nearest container instead of the viewport. And then we're also working on some that would give you similar to rem or other root like accessing the root font size with rem.

No browsers have shipped this yet, but we're trying to get CQM the container font size. Some things like that. So hopefully we'll have those soon too. Nice. Nice. And then, yeah, I've got one question here like the concerning the possibility of state queries. Is there something there beyond what we've discussed already on this kind of, stateful management style is this, does this mean something specific?

Well, it's the idea of. What state is the container in? So there's a few that we have in mind. We're open to more ideas if people have states they want to measure. One of the ones that comes up a lot is is this, is the container overflow auto and [00:24:00] currently overflowing? I don't know if that one's possible.

And that brings up some more layout issues. Yeah. Yeah. More looping problems. Yeah. Yeah. Physician sticky and currently stuck. That one we're working on. There's a few potential issues there, but hopefully it'll happen. And there's a few more. There's an issue on GitHub where we're trying to track what might people want to measure about the current state of the container?

Yeah. Cool. Cool. Is there a good kind of place that people can go to, get involved and, see what's. What's coming down shortly. Uh, Yeah, I mean, it depends what level of detail you're interested in. Sure. I would say Rachel, Andrew, and the folks at web. dev have been doing a great job of regular posts saying here's what's new on the web platform.

Here's what's newly cross platform. All the browsers have now shipped this. So they have regular posts that will give you that level of [00:25:00] detail. I also like to follow the release notes of the various browsers. So all of the major browsers have a place where they post release notes. I think Safari posted Safari 17 yesterday.

And you can go and read through what's new. If you're interested in what's coming a little farther out that's where, it's a firehose, but the CSS Working Group GitHub there is a lot going on there, and you don't need to read all of it. Go to the GitHub, search it's csswg drafts is the name of the GitHub repo.

And find issues that look interesting to you, or even file issues look around some to see if it's a duplicate, but even if it is we can point you in the right direction. There are so many issues there that I regularly post duplicates being an [00:26:00] active member of the group, like none of us are following absolutely everything that's happening.

But you can, yeah, track issues that are interesting to you, comment on them, it's all public all of the work is happening, people are commenting all the time without being part of the group, you don't have to be voting member or something to get involved. Nice. Is there any particular areas, in containers or just more broadly, that you guys are looking for, just more participants, more feedback on things that would be handy?

I don't know. I mean, I would say that we're always interested in what is the author experience, the people building websites. There's a few of us in the working group that build websites as our job. Yeah. And most of the group doesn't. And that's great. We have browser engineers on the working group.

And it's by working together, the various of us, that we figure out how to solve a problem. [00:27:00] But having more input from developers, what are your day to day pain points and you don't need to have a solution always to a problem, to just come in and say, here's the problem. Is there a solution?

And then we can start working on it. That's very cool. Well, Amanda, we've covered a lot in our 30 odd minutes here. Is there anything else you wanted to touch on?

I don't think so. I would say the other big feature that I worked on that I'm excited about is Cascade Layers, and I hope people take a look at that. It's been in all the browsers for a couple years now. I think maybe I talked to you all about it at one point. Yeah, that's a look. Take a look at Cascade Layers.

Look into that. That's very cool. Well, thank you so much for um, coming online and chatting with me, Mary. It's been a pleasure, as always. It's been great. Thanks a lot.