Noel Minchow:
Hi, welcome to PodRocket. I'm Noel, and with us today is Miriam Suzanne. Miriam is an artist, activist, teacher, web developer, and co-creator of OddBird, Teacup Gorilla, and Grapefruit Lab. Did I get all that right?

Miriam Suzanne:
Yeah, sounds good. Hi.

Noel Minchow:
Perfect. Perfect, welcome to the podcast. Yeah, yeah. Thanks for joining us. I'm excited for our conversation today. We got so much to get into. Yeah, it sounds like you got a talk that will have recently been given, or is going to be given soon, when this airs, called Styling the Intrinsic Web. Is that right?

Miriam Suzanne:
Yeah, I gave that a couple weeks ago at Smashing Conference.

Noel Minchow:
Oh, nice. Awesome, awesome. Very cool. We can cover that and talk about it, and maybe touch on some high points, and dig in a little bit here and there where it makes sense. Again, I'm excited to be chatting. But before we get in the weeds too far, can you tell us a little bit about yourself? How you got into web development, and then how your work outside of web dev folds back into that web developer ethos?

Miriam Suzanne:
Yeah, sure. I studied theater and creative writing, and so here I am developing websites. My theater company at some point needed a website, and so I had to learn how to build a website. And it was fun. And I had other friends who needed websites for various things, and then my band needed a website, and people just kept coming to me for websites and paying me for it. And when I moved, I didn't have a theater company anymore, actively, so this took over as more and more clients showed up. I still do a lot of theater, and writing, and making music. I've always enjoyed doing many things at once, and trying not to have a career, but six simultaneous careers. And this one happened to take off in a way.

Noel Minchow:
Yeah, very cool. I would say you've had some success in this sphere, and I was doing my homework and I listened to a video. I think it was The Better Selfs. Better Selfs, that's your current band, is that right?

Miriam Suzanne:
Not currently. I've played with them for a couple months here, but then yeah. Teacup Gorilla is the main one that I'm playing with right now.

Noel Minchow:
Nice, nice. I think you were playing bass in the video I watched, is that your main instrument?

Miriam Suzanne:
Yeah.

Noel Minchow:
Nice, rocking the bass lines. I'm into it. I'm into it. Very exciting. Well, cool. We've got a ton to cover, so I could talk music for hours, but let's talk about CSS first.

Miriam Suzanne:
All right.

Noel Minchow:
I guess the title of the talk is Styling the Intrinsic Web. What is the intrinsic web?

Miriam Suzanne:
Yeah, that's a good question. The term intrinsic web design was coined by Jen Simmons a couple of years back, and she was trying to point out that we've been talking about responsive web design for over 10 years now. And while all of the concepts that led to responsive design and that we learned from doing responsive design, all of those are still relevant, but also the web has changed a lot in those 10 years.
So the initial rules of responsive web design, as a methodology, were that you put percentages on everything. You removed all intrinsic sizing, any sizes that came from the image itself, you would remove that and replace it with a percentage. And that was really useful, but these days we actually have tools that let us keep the size of an image and use that intrinsic sizing information as part of our layouts.
So with CSS Grids and Flexbox we can play with what's responsive and in what ways, and we can rely on intrinsic information from the elements themselves. And I think a lot of the new specs that we're working on play with that idea, thinking about what do we know from the content, and how do we build out from there? So it's an evolution of responsive web design, but just recognizing that there's this new ability, we don't have to always strip out the intrinsic stuff and force our own responsiveness onto it. We can play back and forth.

Noel Minchow:
Yeah, do you think that is a tricky balancing act for devs, especially new devs in CSS, to understand how to think about what elements should be doing that intrinsic, informing of how the DOM should end up being rendered? Where do you start if you're new and trying to figure out where do I yield control to which elements should be dictating how my layouts end up looking?

Miriam Suzanne:
Yeah, I would say that's the hard part of CSS, generally, is... and it's what's new to this medium, as opposed to print, right? Print, we just force everything into a layout, and on the web, we don't know the size of the screen. We don't know the language. We don't know the writing mode. We don't know the operating system. We don't know the user settings. So we have to somehow rely on lots of intrinsic information, and also preferences, and settings, and devices.
And so we just fundamentally don't have a lot of control. And to me, that's the main thing to learn when learning CSS. There was an article back in 2000, and it used to be that if you mentioned it in a conference, everybody had read it. But 20 years later, I recommend checking it out. It's called the Dao of Web Design.
And it's this, basically, manifesto that we need to think of the web as something that we don't control, and we need to let go of a lot of control. And CSS is designed to help us do this, to say, "How little can we style?" And get roughly the results we want across lots of different devices, and browsers, and settings, et cetera. So there's no hard and fast rule. There's just how much can we let the browser do for us? How much can we let the content tell us? And whenever possible, give up control.

Noel Minchow:
Nice, awesome. Well, we're completely off the outline of the show notes, but I love getting into the philosophical weeds here, so let's continue and just dig in. I do feel like there's always been this push and pull of traditional designers wanting control over everything, especially those with a print media background. Like, "No, it needs to look like this. This is our brand, this is our style guide. This is how things have been laid out." And that's always felt a little bit at odds with the foundations of the web, or the guiding principles that powered Markup in CSS and stuff, and what they were trying to do in just portraying information in an easy to parse way.
When thinking about CSS, the developer probably ends up being the balancing act there a lot of the time, like playing that middle man. How do you go about thinking about having branding style, personality that you want to portray, but also, again, making sure that we can be accessible for all these various user needs, device sizes, browsers, anything under the sun. Because again, the web is in this weird spot, where we're trying to make it work for everyone. How do you walk that line without losing your mind?

Miriam Suzanne:
Yeah, I enjoy it. This is part of what attracted me to CSS in the first place. Coming out of this live performance background and thinking, the web feels like a live performance to me. It's different every time. There's too many factors. We don't have control, but we play the set. We do the show, and it's different on each stage. It's different depending on how the audience is reacting. So to me, that's fun and that's how I don't lose my mind is like, I enjoy that aspect of it. So I recommend enjoying it, but if you don't...
I mean that tension is recognized in CSS. So if you look at the original proposal for why we have a cascade, it's because there's a tension between different needs in the system. The browser and device are going to have certain needs. The users are going to have certain needs, and web authors are going to have certain needs, and that tension needs a balance. And the cascade is there to provide us that balance. It's a way of weighing who takes priority in what cases. And we sort of often just think about our own little part of the cascade, and ignore the other parts of it, but yeah. I like to think about that tension, and I don't know if there's a solid answer to how to do that, but it's always...
Well, okay. I would say the CSS is a language that's based in semantics. I mean, this is true of declarative languages, generally. We're not just telling the browser what to do. We're telling the browser why, so we could say font-size: 16 pixels. We could say font-size: 1em. In a lot of cases, those might be the same size, but they mean different things. And so to me, CSS is like... It's easy to write poetry. It's hard to write good poetry. CSS is the same sort of thing. It's like, we can say anything to force the style to be what we want, but can we say it in a way that is meaningful, and reflects what we're intending to do? And using the tools as they're provided; CSS Grid does one thing, Flexbox does something slightly different. We can get the same end result from them on our screen, but can we do it in a way that expresses what we mean most elegantly?

Noel Minchow:
Enjoying the podcast? Consider hitting that Follow button for even more great episodes.
So I want dig into the cascade, and orders, and stuff a little bit, but before we do that, I want to talk a little bit more about something you said there. Maybe you kind of push back on this idea, and I'm sure you'll have an opinionated view here. But I think that some... I don't know, like information purists, would come back and be like, "Well, if there's all these ways that we can be doing things with CSS, and CSS feels like writing poetry, maybe it isn't the best tool for the job." Because it shouldn't take a poet to make a website that's beautiful and also easy to use. Right? It should be a simple thing. Do you think there's any merit to that argument? Is CSS trying to do too much? Have we built this whole web paradigm on these technologies, that maybe have been retrofitted to do something that was never really what they intended to be used for?

Miriam Suzanne:
No. I mean, I would say you could make a counter argument that the web was designed with the wrong goals. But this was the goal it was designed with, was that the user has control, and the device has input, and we should be able to publish once and render anywhere. And that includes even non-visual media. So at the beginning, the reason there weren't styles is because, how are you going to provide styles that are going to be different everywhere? And so CSS was sort of threading the line by allowing you to provide any styles, in a way that the device could ignore. And that was the strength of CSS, was that it could be ignored. And yeah, maybe we're trying to do things now that people would like a different approach to, but I still find that a real exciting proposition, and love working on it. I think there's a lot to be said for it. And if we can embrace that, there's a lot we can do.

Noel Minchow:
Yeah, I agree. I mean, I think the core dream of like, well, CSS should be disableable. You should be able to navigate, and parse the web, and do what you're trying to do without CSS, and that should be fine. I mean, we could go to an audit of how true that is across the top 100 sites? I don't know. I don't know how much of a problem it really is, versus people just standing this up because they have been frustrated at CSS rules in the past, and have stumbled into some project.

Miriam Suzanne:
I think it's a difficult problem to solve, and not everybody wants to solve the difficult problem. I get it.

Noel Minchow:
Yeah, makes sense. Okay, so let's rewind a little bit. So you touched on the cascade. I think this is the thing that a lot of web devs kind of know about, and they know about the browser style sheet, and the user agent. Or the user agents, and then the user style sheet, and all the different tiers. But I think it's something that maybe we don't think about that much. It's just like, "Oh, we write our styles, and we hope everything is fine." For those on the outside that have this viewpoint, what would you recommend they think about? Do you think it's worth revisiting the cascade docs, and looking at how that works, and how browsers instruct the web to render?

Miriam Suzanne:
Look, I made it 15 years in my career building websites without reading the specs. That's fine. I don't think anybody should be required to understand the whole system in order to start playing with it and contributing. But if you're interested in sort of leveling up your understanding of CSS, and what it can do, and how it actually is working internally, that really does help with an ability to then manage it more, and get what you want out of it with less frustration. So it's a useful thing to learn. I don't think anybody should be required to. I think you should absolutely go to, I don't know, any of the website builders and build your own site right away, and don't learn CSS at all. That's fine. Let's make things. But yeah, if you want to understand it, it will help with managing it.

Noel Minchow:
Yeah. I've looked at them before, but it had been a while. And in doing my homework for this chat, I was looking through this spec again and I was, I think I'd never considered it before, but the reversal of priority of the important rules after the key frame animation in the cascade order, it was something I hadn't really mold on much. And I was like, "Oh, that makes so much sense. Now I understand why important rules work the way that they do for the user, and then the user agent, the browser." Anyway, I don't know if there's too much there that matters, but yeah.

Miriam Suzanne:
To just quickly summarize how that works. The cascade basically starts with three origins, which are the browser, the user, and the author, us. And by default, users override browsers, and we override both. But from the beginning, it was important that users have the most power, to whatever extent they can, and then browsers will have to be able to say what's possible not. So importance is a way of balancing this power between the three origins, and it creates three new layers that are reversed. So in the important layers, the browser always wins, and users are next, and we're at the bottom of the stack. So we've got these six origins now, the important ones, and then the normal ones. And then, for animations and transitions to work, they get slotted in there as well. Animations are between the normal and important origins and for-

Noel Minchow:
Like for the author, right? So it's like author, normal, the key frames, animations, then author are important. Right? Yeah.

Miriam Suzanne:
And transitions override everything. So the styles that are happening in the middle of a transition take priority. So you end up with, what is that? Eight origins at the start of the cascade? And then we sort of don't think about origins a lot. We're dealing with specificity, which is down inside each origin. But yeah, that idea that importance is there as a balance of power, instead of being there as a way of just fighting specificity.

Noel Minchow:
Yeah, yeah. Forcing your will. Yeah.

Miriam Suzanne:
Right. That changed everything about how I understood CSS. And I didn't even understand that until five years ago, something, right. And so you can go a long time in your career writing great CSS without knowing that, but once you pick it up, it really does sort of shift the way you think about the whole system. And you don't necessarily have to go read the spec itself. The spec is more useful to browser engineers. There are people writing good articles about this stuff.

Noel Minchow:
Yeah. It did lead me to an interesting question of why is it that, in those final layers, I guess we could say layer, layer, six, seven. Why is it that the browser user agent has final priority in that important stack over the user?

Miriam Suzanne:
Yeah. It's basically just to make certain things not allowed. So if you look through browser style sheets, they only use importance once or twice. And it's just to be a context menu. You're not allowed to set a display on it. We control those. So it's just little things like that, where it's like, "You're not allowed to do that. So we're just going to put a limit in."

Noel Minchow:
Yeah. Probably doesn't really functionally matter most of the time. Again, the only, the only way you could do it is if the user themselves were specifying some weird thing.

Miriam Suzanne:
Yeah. Well, and it's sort of like things that we just think of as not allowed, are sometimes actually specifically not allowed using importance in a browser style sheet.

Noel Minchow:
Yeah. Yeah. Again, it probably is one of those things, like you probably your whole career never thinking about it and it would be fine.

Miriam Suzanne:
Right.

Noel Minchow:
But on a step up, on the author layers, now, I feel like there's always been this pervasive you like, "You should be never, never be using importance. If you're using importance, you've gone wrong somewhere else earlier. You're not scoping effectively." Stuff like that. With this knowledge, and as deep in the weeds as you are, do you think that is true? Or are there cases where the author layer, we should be using importance?

Miriam Suzanne:
I think there are good reasons for it. I think there are also good reasons that we have had that rule. So the cascade was initially designed when style sheets were generally a single file that you could read in 10 minutes. I mean, they were like a hundred lines of CSS, right? And so that's fairly different from what we're dealing with now, and we need better tools to manage it, which is part of what we've been working on. Both cascade layers and scope are sort of about this like, "Well, okay, if we're having so many troubles with scope and with what overrides what in specificity, we should have tools to manage that." So now browsers are adding those tools. Cascade layers shipped earlier this year. Scope is probably coming in the next couple years. And they help us manage our layering of specificity more in a less binary way.
Importance is just sort of this cudgel binary hitting you over the head, and layers let you do it more nuanced. And once you start to make that switch, importance becomes useful again because you can think of it as the balance of power again. Instead of the just, "I need to override something, I'm going to throw importance on there," which is hitting it too hard on the head. You can get some nuance with layers, but then lower layers can say, "But this is actually important, and it should actually not be overridden by a higher layer." And we can go back to using importance the way it was designed.
Probably not a lot, but sometimes I think one example of that is I often see in resets. Adding display: none to the hidden attribute. It's a good initial thing to do. It doesn't necessarily happen all... That's in the browser styles, but it's easy to override from author styles, so it sort of gets overridden too easily. I think that's a thing that I would put in the reset, with importance, because you want that to always win. So it makes sense. And I would throw that into a reset layer, that's at the bottom of my layer stack, and the important version will be at the top of the stack, and it all works out. So there are cases for it, but it's reasonable to be careful with it.

Noel Minchow:
I want to dig more into how cascade layers help this prioritization problem, and can replace what important may have been leaned on historically. But before we do that, I feel like we should contextualize a little bit on talking about scoping, and selectors, and the specificity of selectors, and how that kind of contributes to this conversation as well. So can you just, I don't know, set a background for those listeners, that maybe don't run a ton of CSS, or haven't in a long time. What is the hierarchy of selectors? We don't need to do all the details, but just, how can we think about that, and how does that work?

Miriam Suzanne:
Yeah. So selectors are the way that we latch onto something into the HTML, and say that we want to style, and that's useful so that we don't have to repeat ourselves all the time in the web. Initially, we had to write a font tag, or a font element, in the HTML, and we had to repeat that every time we wanted it. And selectors give us this way to just hook in, grab all of the paragraphs, say, and style them however we want. But then in order to determine which selectors take priority, because now I can select the same paragraph in three different ways, and give it different colors. So the browser's going to have to choose one of those colors.
And specificity is really just a heuristic, sort of a built-in guest, that the more targeted our selector is, the more likely we want it to win. So if we're selecting all of the paragraphs, that's probably a low priority. And if we're selecting just the ones with a certain class name, that's medium priority. And if we're selecting one paragraph with a specific ID, that's probably the highest priority. So it's this rough idea that the more targeted we are, the more specific we are in our selector, the higher priority, it probably is. Did that answer the question?

Noel Minchow:
Yeah, I think so. I think that that's perfect. Let me think. Are there any common pitfalls, or problems, that people run into when they're trying to design a web app? I feel like there's a lot of people in this space, like, "Oh, well, sure, this is a thing that I want to apply to every paragraph, or every line item, or whatever." It's like, I do a generic selector for that. And then if it's a specific thing I use the ID. That seems pretty straightforward, but there's a lot of tooling and stuff built around CSS, and talks, and blog posts, and all these common pitfalls that people fall into. What are the big problems that people still end up running into, even if they kind of have that in the back of their mind?

Miriam Suzanne:
Yeah. Well, I think one of the main problems comes from the fact that we've got roughly three layers there, right? We can select the element itself. We can select a class or attribute on the element, or we can select a very specific single element as an ID. And there's sort of not much flexibility on the first or third layer. We only have a lot of flexibility on the second one. So we've sort of developed this best practice over the years of don't select things by tag, don't select things by ID, only use classes. Which there's reasons for that, because we have more control over classes, but also that's pretty limiting.
And so then we end up in this situation where we're fighting over how many classes, and how do we name the classes? And its classes are all in the same name space, so we've lost all of our ability to control what takes precedence, because we've decided that the first and the last are too narrowly defined, or we don't have enough control over them. And that I get it, but then that's how we end up with best practices, like BEM, Block Element Modifiers, syntax, or other syntaxes that are like, "How do you name and scope all of your classes?"
And we're sort of doing that for CSS. And it's why we added layers, and we're working on scope, is you shouldn't have to do that in a naming convention. You should be able to tell CSS what you mean. What you mean is, "I'm trying to target something that's in this scope, and I'm trying to give it this priority." So we're taking what was a heuristic in specificity. That's still going to be there, but we're nesting that inside of layers and inside of scope. So you have some other ways of getting there.

Noel Minchow:
Yeah. Yeah. Cool. Yeah. It's a tricky problem too, because it's kind of this many to many mapping you're trying to maintain. There's a bunch of different ways, like, "Well, do I have a class just for this specific padding, and do I apply that to all those things that have it?" Or do I try to set up the hierarchy so it's only like, "Well, when it's in this realm, that is where I care about, this padding. I don't want to put the same class on paragraphs, and images, and everything." Those should have separate class hierarchies and all that. Yeah. There's a lot of complexity in there, and there's a lot of, I think, ideas that sound good when you start working on it, and then you end up super down in the way you're like, "Oh no, I've done everything terribly. And..."

Miriam Suzanne:
Yeah. And part of it is where things get rough, is when there's a disconnect between what we mean, what we're trying to convey, and what the browser understands from it, or can understand from it. And that's why we're sort of trying to give more of these tools that let you express the meaning. What does block, underscore, underscore, element, dash, dash, modifier mean? Well, if we can express that as a scope, and a selector, and a selector in a wear function, for example, we can sort of say, "All right, let's actually layer these out."

Noel Minchow:
Yeah, awesome. I guess, yeah, for those listening that don't know, what is a scope? How does a scope work?

Miriam Suzanne:
A scope it's similar to... Like right now you can nest selectors. So you can say, "I want a title inside of a post." But people have found that a little frustrating, because sometimes you've got comments inside of posts, and the comments have titles. And then you're like, "Well, that ancestry tree, that's too far in a post. I want really the post title. I want the title that belongs to the post." And scopes allow you to do that by setting a lower boundary. So instead of just saying, "A title inside of a post," you can say "A title that is inside of a post, but not also inside of a comment." So I can create a scope that says, "The scope of a post is just from the post to the comment section, and when I'm styling something in there, don't also style it in the comments."

Noel Minchow:
Yeah. Yeah. They are super handy. We had Adam Argyle on set, several months ago at this point. He's in the CSS working group as well. We've talked quite a bit about scopes, and how they solve this problem. Anyway, yeah. It's one of those things where it's kind of hard to talk about abstractly. I think you did a good job with your example there, but you see it in the wire, like, "This is it. This is what scopes are for. I got it," and it feels super good. The code is good.

Miriam Suzanne:
Yeah. A thing is sometimes a donut. It has other things inside of it, and we want to style the thing without styling the things inside of it.

Noel Minchow:
Right. Exactly. Yeah. There's this, again, in the web, we commonly have like, yeah donuts a great term. Like a rapper thingy, and it's like, "We want to style this, but stop. Don't do anything to the stuff inside. I'm bringing that in from elsewhere." It could be user content, who knows, a bunch of different stuff. Yeah, so that is super handy. Okay. And then the other tool you kind of kept touching on, and we alluded to before, but cascade layers, and being able to define those yourself. How does that work, and how is that? How is that helpful in this problem?

Miriam Suzanne:
Yeah. There's an @layer rule, where you can put blocks of code inside of a layer, and layers stack up similar to origins. So in the same way that you start with the three normal origins, and then if you add important to something, it gets flipped into a reversed important origin.

Noel Minchow:
Mm-hmm.

Miriam Suzanne:
Layers work the same way. So you define your own layers. I mean, that's the difference, is it's inside of the author origin. You can define any layers you want. And in those layers, they stack in the order they're introduced to the browser. So the browser runs into a layer name, and it says, "Ah, this one I haven't seen before, I'm going to add it to the stack." And you can actually sort of scatter your layers throughout. It's okay if you have a reset layer, and then at the beginning of your document, and then at the end of your document, you add something to the reset layer. It will get pulled back up into its original position.
So you can say at the beginning of your document, "Here are the layers that I have, in the order that I want them in." And then you can put code in those layers whenever you want. And they'll get slotted in priority wise. So you can say, "I have a reset layer. I've got some defaults in a layer. Defaults will over always override resets. Then I've got a theme layer. Theme will always override the defaults." At that point, specificity only matters inside each layer. So theme will always override defaults, no matter what the specificity is. And I've been playing with this, and it means you're a little bit more free to use IDs, because you can throw an ID into your defaults, and then your theme can easily override it. You don't need to worry too much about like, "Well, I got too specific in the last layer. That's going to cause problems for me in this layer."

Noel Minchow:
Good, good. Yes, that's a great explanation. So I feel like it's, I guess, important to point out that when thinking about layers in this way, I feel like we so often think about CSS in terms of selectors and subsets of the DOM overall, but layers are always applying to basically the whole document, right? Is that?

Miriam Suzanne:
Yeah. I mean, layers don't care about the HTML document. Layers just say, "When there's a conflict between my styles, which styles take priority. They build on that idea of CSS being layered from the browser, and then the user, and then the author. And they say, "Well, actually, we sort of have different origins in our work these days. We have the design system, and we have the reset, and we have the component library, and these are different layers, and let's give them priorities and say how they should interact with each other more explicitly."

Noel Minchow:
Yeah. I think theming, which is what you were using as an example there, is a great example. Because like it's such a clear like, "Oh, well then we can just swap the layer out,' and it does everything it wants. It's easy to go read in by itself. It almost feels like the layering system, it is functionally useful, but it's really good, like an organizational tool. A way to think about these, and you can make use again. Empowering us to start using things like IDs again, which is a handy tool.
It's nice to be able to go, like, "I want this text here to be bigger than everything else. I know it's only ever going to be... It's the title of the page. It's the only thing that matters." But we want to change that if the theme changes slightly, or whatever. Change the background color, who knows. Yeah. So I think that is a very good example. Yeah. I guess, when were layers introduced to the spec? When did browsers start implementing them?

Miriam Suzanne:
All of the browsers released them publicly in February and early March. So end of February or early March, they came out in all of the browsers.

Noel Minchow:
Awesome. Awesome. This is like totally out of the scope of what we plan on talking about, but are there tools that are polyfilling layers, like a build step for CSS?

Miriam Suzanne:
Yeah. The OddBird team. OddBird is the company that I started with my brothers. We worked with the PostCSS folks who do AutoPrefixer. And there's now a cascade layers polyfill in PostCSS, because layers are just above specificity, you can sort of fake them with specificity. It's not pretty, but we can pre-process the style sheet and say, "Anywhere there's a layer, let's turn that into a selector with the right specificity." So that's what it does. It doesn't do everything that the spec could do, but it gets you pretty far.

Noel Minchow:
Nice. Awesome. Awesome. So yeah, there's very little holding devs back from going in and jumping in at this point.

Miriam Suzanne:
Yes.

Noel Minchow:
Cause yeah, that [inaudible 00:38:21]

Miriam Suzanne:
Yeah, I would say the main thing is, because it's so architectural, it's sort of like... The best way to start with it is to rewrite all your styles. And you don't have to, you can start putting layers, layers come under unlayered styles, so the styles you have right now will win over layers. So when you start using layers, start by putting your resets in there, your lowest priority styles go into the layers, and you can move over slowly like that. But yeah, they're architectural. Everything ends up in a layer if you're using them consistently. So I think that's going to be the main blocker for people moving onto them. They're easier to use on a new site, than to do a whole refactor all at once.

Noel Minchow:
Right. Right, right. But I mean, I don't feel like it'd be too painful to migrate slowly. Like you said, pull things out a little bit, and you're like, "Oh, well I pulled this into a layer. We may care about something else that's like up at the top level, and not in a specified layer. Let's pull those rules in now into like our new top layer."

Miriam Suzanne:
And do that from the bottom. Do that from the least important styles, to the most important styles, or in terms of what you would consider priority.

Noel Minchow:
Yeah. Yeah. So you're not breaking anything accidentally, like, "Oh, oops. I broke this, the About page, that no one ever looks at, because I wasn't thinking about it." Yeah. Yeah. Awesome. Cool. Yes, okay. I think we've painted a pretty good picture of layers at this point. I think the other topic in your talk that you talk a little about are container queries. Can you kind of contextualize those a little bit?

Miriam Suzanne:
Yeah. Container queries are coming so soon. They're going to launch in at least two browsers over the summer, and probably a third browser by the end of the year. But container queries... So if you've ever used media queries, which were the basis of responsive web design, right? Media queries let you measure the size of the browser window, and say, "I want to change the styles depending on the size of the window." Media queries have been extended to do lots of other things too. You can check what type of inputs being used. You can check preferred color scheme, all sorts of things.
Container queries are a very similar idea, and similarly are extending beyond just size, but they let you look at something smaller. They let you query an element on the page. So you can say, "If the elements container is larger than a certain size, I want to change how it lays out." So say you've got a component that has an image and some text, right? And in a small space, you want it to be image up top and text below, and then as the space gets wider, you want to put them side by side. Right now, it's hard to do with media queries, because if you put it in the sidebar, or you put it in the main area, it's always looking at the same browser window. It doesn't know the size of its container, so you have to get tricky to do it. Container queries would just let you say "My main area and my sidebar are containers, let me query them. This thing when it's in a tight space, lay it out this way. When it's in a wide space, lay it out that way."
That's what we're getting first, those size container queries. But then also, there's lots of ideas for other things you can measure on an element. Can you check its background color? Can you check its font-style? Say, when my container has a font-style of italic, ems should have a font-style of normal. So we can sort of toggle back and forth, or something. So those are also extending, and maybe down the road, we'll be able to say, "When my container is positioned sticky and stuck, do something, or other sorts of..." So similar to media queries, they'll extend beyond just size, but size queries are what we're going to get first. Very soon.

Noel Minchow:
Yeah. Nice. Nice. I feel like that the obvious benefit there, is what you spoke about. We often have this case where it's like some element that's way deep in the tree, but we know when certain media thresholds are hit, we need it to pop in and be a different thing. And just end up with this gross thing where you have this whole hierarchy that's poorly defined of how the responsiveness is supposed to work. Anyway. I think that'll be a lot cleaner when you can just be like, 'Well, I know I can think about this element by itself," and that's all I really need to-

Miriam Suzanne:
Yeah. And to tie this back to the very first thing we talked about, this is sort of that intrinsic thing, and that thing where we want to not get too explicit. So CSS gets fragile when we have to say, "Okay, well when the window is this size, that means my sidebar is this size. That means things inside of it." And we have to do all that logic and put it all in the code. And that's when CSS gets fragile, when we have to be too explicit about what needs to happen.
And it's much nicer, and more resilient, when we can just say, "Look, just check what size this space I have, and just let me change it based on that." And every time we can be less explicit, or more meaningful, we're expressing just the meaning of what we're trying to look for, instead of expressing how to get to that meaning, all the steps to figure out if the sidebar has enough space. Instead of laying out all those steps, we're just saying, "Just check. Just check and let me know."

Noel Minchow:
It feels very human, as well. When you're sitting there designing, working, developing on something. You're looking at that little element. This is what I care about. I just want to know how wide this thing is, and it's got to look different when it hits a certain width. I know what I need to do. So I feel like, yeah, having the friendly tools, I think, will continue to break down this CSS is this terrible thing that is always a nightmare. It's like, "No, it's better now than it used to be. It's incrementally..." Even though there's a wider feature set, I feel like it is less painful than it was 10 years ago, and it's getting better every day.

Miriam Suzanne:
Yeah. I mean, it's this balance with any tool or any language, right? It's like there's advantages to simplicity, but when simplicity means you don't have control over what you need control over, that's a disadvantage. And so you have to find this balance of adding features that make it feel simpler by adding a little more-

Noel Minchow:
Mm-hmm. Yeah. And I feel like it is also... Like it's beyond that. It's also just more powerful, these new things, because like I'm thinking of, I guess, a container query is the obvious use case that jumped out to me, was like, "Oh, well now if you have responsive subsets of a website, right? You have, I don't know, sections that you can drag around or something, right? You can make each piece behave like you want it to, without having to have crazy selectors that are watching for these arbitrary element movements. You can just have it all declaratively right there.

Miriam Suzanne:
There's actually a great demo. Max Böck built a great demo in CodePen of a container query bookstore. So it's these book components that you can drag around into your shopping cart, or into a featured view, and as you drag them, they change and display differently to fit their context, which is pretty cool.

Noel Minchow:
Well, yeah, we've covered a ton. I guess, looking forward a little bit more, is there anything in this realm, in these topics we've covered, of this empowering devs, and more responsive design, and being able to do things a little more intuitively. Intrinsically, if we use your topic there. Is there anything on the horizon that you're excited about, or that you're thinking about right now?

Miriam Suzanne:
Yeah, I mean right now, so the main three that I started working on were layers, which has shipped, container queries, which are shipping soon, and we've got to get scope done. So that's still coming, but there's a lot of interest in a lot of progress there. So that's the main one at the front of my mind, is we need to get scope done. But there's a lot of other interesting things happening, that sort of take parts of these features and fold them together. So container size queries also come with container units, similar to viewport units, but referencing a container.
That's useful for some typography you can say, "When I've got more space, make my font bigger," some things like that. But there's a lot of interest in saying, "Okay, but I actually want my fonts to have this almost animation-like logic. It's not that the font is going to animate, but I want it to start growing slowly, and then grow faster, and then slow down depending on sizes."
So we want this easing curve of font size, or something. People like Scott Kellum have been working on this a lot, and have tools that make it happen right now, but in almost tacky ways, roundabout ways. Wouldn't it be cool if we could say, "Here's the rules for transitioning my font size as the container grows. Here's the easing curve that it should follow." I think we're getting to things like that. I think those are going to be possible. I think things like checking if something is positioned sticky, and currently stuck, if something is in the top layer. Those are all exciting sort of extensions on these ideas.
Scrolling to animations are happening. People need to be careful with those, but that's fun. Yeah, there was one more I was thinking of... Oh, color spaces. Color spaces, you should be watching for that. They're part of Interop 2022, which is all the browsers agreeing that certain features should ship in every browser this year. There should be Interop by the end of the year on new color spaces, which are going to be very cool. So keep an eye on that.

Noel Minchow:
Awesome. Well, is there anywhere else you'd like to point listeners to? Any projects? Anything in particular? I guess is the talk available online anywhere?

Miriam Suzanne:
I think there's a shorter variant of the talk available on the OddBird website, Smashing Conference hasn't released video of the long version yet. I'm sure I'll give the talk to other places as well. I post on oddbird.net when I'm giving talks, or also articles. And the team also writes some great articles there. So check outoddbird.net. Yeah, and I try to take notes on the features that I'm working on. I have a public notebook that you can check out if you're interested, css.oddbird.net is just sort of my thoughts on various features, and what I'm working on, and what I'm looking at next.

Noel Minchow:
Nice. Awesome. Awesome. Well again, thank you so much for having this conversation with me. I know we kind of bounced around, and went all over the place, but I got a lot out of it, so I've really enjoyed our conversation. So thank you so much for joining us. It's been awesome.

Miriam Suzanne:
Thank you. Lovely talking to you.