Smart Layout Patterns with Modern CSS with KEVIN POWELL — SmashingConf New York 2024
KEVIN: Thank you so much, Vitaly, thank you, everybody. I'm super-happy to be up on the stage today to talk about creating smart layout patterns with modern CSS. And especially early this morning, we had lots of talks about AI. And you might be wondering is that why I'm talking about smart layout patterns. Some people are happy to know, some are disappointed to know,
we're not here yet. Maybe one day. But that's not what we're going to be talking about today. Before I talk about smart layout patterns, I want to talk about modern CSS. As Vitaly said, there's so much happening with CSS these days. It's incredible, really. Right? It's just this really fast pace of change that's going on. And if I was giving this talk just a few years ago, you might have thought I would be talking about using Flexbox and Grid that and would be the focus of the talk. These days, though, it could mean so much more. This was a really quick list I through together last night when I thought of adding this slide, and I'm missing a whole bunch of cool things on it. If you don't know any of them, look up the has selector, positioning,
I didn't add on here, scroll-driven animations. Anchor positioning I think a lot of people here would be really excited about. If you haven't seen it yet, go and dive in and look at that. What I want to talk about today -- or actually, before we get to that, one of the good reasons that so much is happening in CSS, as we mentioned, I have a YouTube channel. Yeah. I'm at 840 videos right now. And I'd say 820 of those are about CSS. And despite that, I really don't have a shortage of
topics. People have asked me if I think I'm gonna start talking about something else just because I'm getting bored. And it's actually the opposite. I can't even decide what I'm going it be talking about next because there's so many things I'm excited by. What I'm going it talk to you today about is something I have talked about quite a bit, which is container queries. I don't just want to talk to you about them and say they're awesome. I actually want to you bring you on my journey. I
fell in love with container queries the minute I heard about them and played with them. Then fell out of love with them, I didn't like them, I wasn't finding use cases the way I thought I would. And then I realized they were awesome. For those that didn't use them and didn't find the use cases, hopefully let you fall back in love. and for anybody who didn't, you can see the first two steps. Really quickly, just so we're on the same page, what a container query really is. And a container media query. Most people are familiar with those. I have set up this layout. This is the first demo, I think the first demo I ever set up using container queries. The
first time I had to update the CodePen with the new syntax. When I made this, the syntax wasn't finished yet. I did this with the media query, I hit a breakpoint of 750 pixels. And at that size, the layout shifts and the image is to the side instead of stacked on top. I'm doing that with the flex direction of row there. If you want to do this with a container query, it's pretty easy. Keep everything the same, but you keep @container instead. But you get a little bit underwhelmed. We're gonna change the size here as well. But you get a little bit underwhelmed when you do that,
it doesn't work. That's when you need a defined container. I'm gonna add a red dotted outline around here just so we can really visualize what the containers are. On all of these, I have a card. Right there, you can see the article is the card. And then inside of there, I have the card layout. So, the container is the lotted line and the layout is the piece inside that I'm manipulating. You can see now the cards on the top are different from the cards on the
bottom. For designers, this could be -- we moved into a this component-based world and this is what we wanted. This is a feature that we wanted for a really long time and we finally got it. Where the layout can depend on the space available. So, those cards on the top are switching because they have 300 pixels. The ones on the bottom don't. And then when we get to a larger size, eventually they switch over too. This was something we were told was impossible for a long time. At the top of the list of the features that people wanted in CSS. And the browser engineers
kept telling us it's impossible. But they're actually really smart people and eventually figured out how to do it. They gave it to us, people like me got extremely excited, and we got other people excited. And once they got to the point, they're over 90% browser support right now.
They're available in all the major browser engines, no one really started using them. Which was kind of disappointing. It was sad to not see them being used anywhere. But I went through this too. I had a playlist of videos looking at all the really cool things you can do with them,
and then started struggling myself in finding use cases for them. And, of course, you have to start wondering why? This was a question that started coming up a lot in the CSS circles maybe a year ago, six months ago, somewhere around there. Where people that are really into CSS were talking a lot about it and wondering why. Chris Coyier wrote a blog post on it. In his post, he thought once they came in, 75% of the use cases from media queries would be replaced by container queries and clearly that didn't happen. And he brought up some good points in the article about why. There was a lot of social media back and forth and different ideas that were going around. One of the things that came up a lot was some of the limitations around them. So, one of
those limitations you sort of saw already where I had to add a contain. I had to define a container. And one of those -- because we have to define the container, we'd run into situations like this. Where I have an intrinsic layout. So, an intrinsic layout is a term coined by Jen Simmons. It's a layout, it changes and adapts to the browser without the need of media queries, which is really awesome. I'm doing this down here just with three lines of CSS. The important one is this grid template-columns, it's a long declaration. But gets the job done, and the smallest the column can be is 225 pixels. If the browser can fix more, it squeezes more in, and squeezes in
another and another. This is super-useful and a really great pattern to use. But the problem is I don't have a solid breakpoint to use. With a media queue, it's a magic number and it's fragile. It felt like container queries should be able to do some stuff with this. But let's say the one I have the border on right now, if I wanted that to stretch across two columns at one point, I can't do that pap and it's really frustrating. So, over here I tried doing it. Where I have a defined container. And then I'm using a bit of modern CSS there with card has image. So, the card that has the image should change and span across two columns. But it never actually reach this is width
of 100 pixels. Because as soon as there's enough room, the layout shifts. So, it never hits that point and I can never have this contained thing that's looking outside that have and I can't switch this over to being the card container either which is actually what I need to do in this indication. Because the card is inside of the card container. This isn't gonna work because the media query can't query itself. This would break the web -- your browser. It's just impossible. You
can't look at the size of the element itself, you have to look at the size of other things. You can see that doing that actually caused some weird stuff to happen. But I think that's because I have another media query or container query set up in another spot. And it started causing, actually, I did have something down there that was causing -- sorry about that. I think on my main I did. I thought I deleted that before I do this demo. There we go. Normally when you would say:
The span too, it wouldn't work when you had this as -- let's do it again -- card-container. And that doesn't work. And that becomes frustrating when you can't query your own size. When you can't query your own size, a lot of the things we want to do actually start falling apart. And it felt like this limitation that was preventing us from really taking advantage of all those situations that everyone was envisioning when we thought we were getting container queries. The problem is not container queries, it's that we have been using container queries wrong. It's not your fault you have been using them wrong. Maybe it's my fault because I have been putting out all those videos
and didn't show the cool stuff you could do. But I couldn't figure it out either. I'm not smart enough, I guess. But I wouldn't say it's really anybody's fault. I would say it's something's fault. If I were to blame anything or anybody, it would be the media query. Not that there's
anything wrong with media queries. Media queries shape the web we have today. If we didn't have media queries, we would have run into a lot of problems along the way, modern web wouldn't exist the way it does, it would be really hard to make responsive layouts. Speaking of which: This is the article by Ethan Marcotte from 2010 where he coined the term "Responsive web design." It's almost 15 years ago. And a big part of what he talked about in this article was using media queries to create responsive websites. We have been using media queries for a really,
really long time at this time. Because we have been using them, we understand how it works, we understand the limitations of it and we have gotten really good at creating different things with them. When we look at a container query compared to a media query, it's just like the fun house equivalent, right? They sort of look the same. They look a little bit different because the word is different there. But more or less the syntax is the same, everything else is the same. The only difference is a media query looks at the viewport. So, it's evaluating is the width greater
or smaller than whatever number you put there. Usually it's pixels. Sometimes you might use amaran. And it's the same thing, looking at the size of the container instead of the size of the viewport. sort of same thing. This is how we have been trained to use them. That's how media queries work. It's the only way we can use media queries. But it wasn't until recently that I discovered there's actually more that you can do with container queries and a lot more that's possible and it opens up these smarter layouts that we can create. We can lean much more into intrinsic designs and building out sort of new intrinsic patterns and working with intrinsic designs and following the breakpoints that they're actually creating. And it's really, really exciting.
I wish I could say that I was smart enough to have that lightbulb moment and discover that how this works, but it was all because of a blog post, actually. This was a blog post by Andy Bell on his Piccalilli website. From a year ago, which surprises me. If you don't know Andy Bell and the Piccalilli website, strongly suggest you go and check it out. And it looks good. He just recently redesigned it. In this blog post, looking at the dribble design and making it into a responsive
website. It's a very in-depth post, check it out. If you don't like seeing scrolling screens, maybe look a away for a moment. I'll let you know whether I'm done. I'm gonna scroll a lot. It was a really good post, like I said, really in-depth. Lots of interaction and examples that you can play with along the way as you're going through it. And then it wasn't until right here that I got
to the part and I stopped scrolling now if you weren't looking. When you got to this point right here where I discovered something and it stopped me. Wait a second, if you're gonna come to the article and read it, read the whole thing, don't skip it. It's a good article. But the important part was this: @container, greater -- you can use the greater than and less symbols, do that in media syntax, supports it. Width greater than 70vw. That looks weird. You would never do that
with a media query. In this slide, I'm saying it's kinds of useless. It's totally useless. Our media, which is the viewport, is always bigger than 70vw. It doesn't make any sense there. Once again, media query looks at -- it evaluates: Is the width greater or smaller than a certain number? Container queries evaluate if the container query is greater than or smaller than a number. When we use viewports, we have done something different. All of a sudden, we're querying two different
things. This might not seem like a big deal, but it's a really big deal. Now I'm comparing the width of one thing to the width of another thing. And both are changing sizes. And that opens up some really interesting possibilities. So, if we look -- I made a very simplified example to what Andy did. The design is terrible, I apologize to the designers in the audience.
I have a simple two column layout. The layout is created with the media query where I'm using Grid to make the two columns. Not fancy. If I'm greater than 720 pixels, two columns. And they stack, and then a giant image that fills up the viewport and the user leaves because thing your website is broken. We don't want this to happen. So, this is what -- and just -- I'm doing an exaggerated example now. I'm gonna crop my image a lot. You don't do this necessarily because then you're serving up a giant image for no reason. It highlights really well why this works. So, in my HTML at the top here, we have the split. I have an adaptable image div with the image inside of it.
Then I have the article with all the content in it after that. So, what we can do is -- let's go bigger far second -- we can bring in a container query that uses that 70vw trick right here. And when I do that, now when I get smaller, all of a sudden that adaptable image is taking up the full viewport width. It's now larger, even though the screen size got larger because it's stacked,
it got bigger, it hits that point, and all of a sudden we can do some other styling and we can fix our layout and make it a little bit better. You might be wondering, couldn't I just do this in this of the media query on the top of the page? I could do this for this one specific use case. But generally speaking, if it's for one specific use case, it's kind of crappy. In this case, it would be working for this one specific breakpoint and nothing else. And change it so that it could work. And use this in other situations. So, for example, down here... I could bring in some extra columns of content at the bottom. I'm using the adaptable image
in these as well. And that just -- and I'm using Flexbox for this. So, if I come and take a look, I don't know when the breakpoint is gonna happen here. Let this go down. Because I'm using Flexbox, I've set sort of like a minimum-ish size on those flexible items. But I don't really know when this is gonna change and they're gonna wrap. I'm using flex wrap, it's intrinsic layout, I don't know
when things are gonna change. The browser is figuring that out. One image is wrapped, it has the adaptable image and adapts, the other two on the top don't. Which is something you can't do with a media query, no matter how hard you tried because you're dealing with the same thing in multiple different places. And same thing on this side, then all of a sudden they all stack. Now, I thought that was really cool. I really liked this. I felt like there was more. There should be more possible. And I kept looking for different ways and trying to force things to work. And I liked that pattern, I have used it in a view different ways. Clever-looking for
viewport and wide-angles and stuff. Someone else pointed me in the right direction, in this case, it was Miriam Suzanne, I put a video up on YouTube with one way of doing something, she replied with a way using container queries. It was on Mastodon. First the part, it's the inline size, it's a logical property. Treat that as a width for all intents and purposes today. But then there's calc there, calc 32ch times 3. Blew my mind. First of all, you can use a calc inside a container query? Yes, you can. And you can use them in media queries. We will show in a minute. Just to compare, a media with greater than 60ch, the width of the browser and the 60ch,
it's characters. It's roughly the width of a zero character at any given font, change if you change your font. I'm saying 60 characters wide. It's getting it from the browser, not the CSS. It's basically a fixed number. It's sort of 60, unless the user changed their user preferences. It's
kind of the same as saying 600 pixels or whatever. Putting in a set number. With the container query, very similar, but the 60ch is coming from the size of the container. This might seem like a really small difference, but it's actually a really important one. So, here once again I did the red outline thing just so we can see what the container is. And I'm going from this is
basically what Miriam had shown in her post. We go from stack content to three columns. And down here, I'm setting it up with 30ch right there. And actually for the developers in the audience, why 30ch and not 300 pixels? The designers in the audience are saying that's kind of cool. Designers know we have ideal line lengths, minimum and maximum line lengths. I can actually say when I have a minimum line length of 30ch for each column, then I get the columns. And never worry about overly-squished columns with text that's too tight. This is rough, we have the padding and the gap that come into count. You have to think about that. But it's
kind of nice. And if I come on my HTML here, because font sizes are inherited. You don't change it element-by-element. But if I change the font size on the body or the HTML, that font size gets inherited and the breakpoint changes along with it, and everything scale up proportionally.
All of a sudden we have this smarter layout that's aware of the font size. You would be using fluid layouts using clamp with your font sizes and this is gonna adapt to it. It's really, really cool. Just in case you're wondering for anybody, you could try to do it with the media query. The calc, everything is going to work. The only problem is, again, media queries don't actually see the font
size of the thing that you've declared. So, you can see it's getting really, really tight here. If I change my font size here, let's make it really big, 1.75, the breakpoint's at the same place. Now I'm breaking my layout. The reason for that is media queries can never see relative font sizes here. Even if you use REM, anything like that, using the browser setting. In the media query,
you can change the font size and create circular logic and crash the browser. They don't let us do that, there's a good reason. They don't have the power to adapt and create these layouts like this. And... oh! One last thing, actually, I wanted to mention something else. I forgot what it was, though. Oh, just here, yeah. With the 30ch times 3, you might be wonder for we could
use a variable for that. That would be really nice if we could use a variable. Because then you could have the two 3s set to that variable and it would just change to whatever you want it to. It's something that we're supposed to have, but no browser has figured it out yet, I guess. We don't have it net. It's something that could potentially come down the line and be useful to set as variables. It's not bad doing it like this. It's straightforward using 90ch, it's magic number-y again. And you can put the comment in your code to let people know what's actually happening. This got me really excited. I was like holy moly, it's a really simple thing. But all of
a sudden, that unlocked a few other things that I had been struggling with for a really long time and it sent me down a bit of a rabbit hole. And it brought me back to this layout that we looked a the earlier where I was struggling in getting this layout to adapt in the way I wanted it to. So, in this layout, again, it's an intrinsic layout. I don't have control over where the break points are happening. The browser is figure out it based on how much space the grid autofit has. Take a quick look, I have the grid autofit and even this the articles that are in there.
So, before what I was trying to do because I was so trained with how media queries work and this idea of components, that the component should see the size of itself that I just didn't get my brain to get to this point until I started playing with that pattern that we were just looking at. Where I said, well, wait a second, I'm using min and max here. And in min/max is figuring out where the break points should be happening. Updated to pixels, 25ch minimum column size and then I get a new column. So, I can make that grid autofit into a container just by saying container type, inline size. If you're wondering about that, I sort of glossed over it before. Just do this. And that makes your container. Another option you're basically never gonna use, size. Inline-size,
it becomes a container. And again, inline-size is left to right most of the time. So, here I have a container query they created. That I'm gonna turn on and what I'm saying now is 25ch times 2. For my container. Because I know if I can fit two columns, because I said minimum column size is
25ch. So, when I get to 25 times 2, I now have two columns., so when I get there, I can actually span two columns all of a sudden. Change the layout of that featured card. I tried doing this with media queries. It's a magic number disaster that you don't want to try to do. When you change anything
by 1 pixel, the whole thing just collapses. In a situation like this, whatever I throw at it, it's always gonna work. It's cool to do that and have the layout adapt. Might notice the plus 1, and I will talk about that in a second. But just for fun, bring in a little bit of an update here. When you get to another size, adapt again. Stretch it up and down. Four columns, a different layout. And using subgrid to make sure the image matches the cards on the top. I don't have time to dive
into how that works, though, sorry. So, yeah. Here I'm just saying 25ch times 4. And because that's when I know I have four columns. Now, you'll notice the plus 3, the other one at the top had a plus 1. See if you can think about why I might be doing that. There's a good reason. This is where variables would be really, really, really nice in our media queries and container queries. But it's because when I have four columns I have one, two, three gaps and each one of my gaps is 1 rem in size. That's what I declared higher up. You have to get this to work -- variables -- I'm waiting for the day. But I find I can do this, a quick comment in your code makes that connection and
makes everything work really well. Again, the one problem there would be if you have different sizes that are coming for your gaps. If you adjust your gaps at different sizes, you have to repeat which might be annoying. And one limitation that might be worrisome. What happens if you have a card,
in this case, let's just look really fast. It's up here. My card, I did it in a bit of a contrived way instead of putting a class of featured card. So, I said card has a direct child that's an image and it's also the first child. What if I had a card somewhere else that meets that type of thing? Or maybe you just did a featured card class like a sane person would have done. And then you would have -- you could potentially run into the same issue, though. Where it I take that and let's just say for fun I put it at the very top of my section. And I don't want in card at
the top of the layout. The layout is changing, broken with that, I don't have subgrid anymore. Maybe I don't want that breakpoint. I only want this. And those numbers become magic numbers if I'm using this outside of the context of my grid autofit. So, some people might have noticed... where... here on my container type above that I have a container name. And you can name your
containers. So, I can actually come in here and when I declare my @container, I can say: Grid-auto-fit. And those styles only will apply if the container query evaluates as true and it's in something with a grid-auto-fit in there. Now you can see the one at the top is kind of broken. It doesn't have any changes happening. Whereas the one at the bottom is spreading across two layouts. I can make she's things without having to have some weird modifier classes. Keep the styles for this thing all together in one space and still define the different areas where the changes could be happening without having ten different -- again, whether you're using a modifier class or in a different way. But then I can use the component wherever I need to use it and it's going to adopt.
Instead of having to place it in there and read from the codebase to figure out what the modifier class they need it. In the long run, you're creating something that's a lot more robust. It's gonna work when you're using them in situations that you've accounted for. To me, it's really, really exciting. Yes. Nothing else to say on that one. Now, we get to the part that I'm really excited about. This does involve a little bit more modern CSS. That's not as well-supported. Just so you know. But it's making a lot more things that are really exciting possible. It's continuing off of this idea of container queries. Where it's part of the new spec for style queries.
Anybody here style queries? Good. That's exciting. So, style queries build on top of media queries. They're available in Chrome and shipped in the latest version of Safari. Browser supports 71, 72. They're probably not ready for production. But you can start thinking about different things you could do with this. Here is a layout that I was working on for our project. For a course of mine, actually. And simply, it was this thing and it was used across -- it was for a blog. It was used across a whole bunch of pages where I had some columns of content. But when we go the to narrower
sizes, especially for mobile, we turned it -- we didn't want them to get squished or stack. It would look cool if we could have an overflow grid. Call it overflow grid. Goes left to right, and works much better on mobile than desktop, obviously. But we wanted some horizontal scrolling
for that. And this worked on every single page except for one specific situation. And that one specific situation -- it worked 50% of the time. Which was really annoying and I'm sure you've run into situations like that. Where you've made a perfect solution and then get a random curve ball thrown at you and you're just really mad at it. Whoever came up with whatever you're doing. So, here -- oh. I already had something in my CSS that I didn't think I had. We're gonna turn
that off really fast. I don't know what I did. Oh. It's right here. Cool. Spoiler. Awesome. So, here I have the same component in this section and down here. They work exactly the same way, no difference. I copy and pasted it into this upper area. But in the upper area, what I've done, come look in the HTML first, I have this hero class that's up here with the split. The split is the exact same one I showed you before. Where when it's wide enough, we go up to two columns. But when we go up to two columns, it looks kind of weird with this
horizontal scroller up there. Everywhere else in this situation this works perfectly. But this is being set up with this container query. And the problem with this container query that we set up, take a look, overflow grid. I have a bit of custom property usage in here. Overflow grid, making it go left to right. And the container, larger than 900 pixels, that's the side scrolling that were
set up. Which works absolutely everywhere I was using you it, it's a container query and using the smaller version and it's giving me the horizontal scrolling I don't want to have. I was so frustrated. And then I thought, well, what I could do is use one thing up here. So, actually, I
have to comment something else out really fast to get -- we're gonna comment this out. What we could do is come inside where they have split class. Some people love this, some people hate this. But inside the container query. Ampersand hero. This is with nesting, the ampersand is a place holder
for split. If you nest, nesting is part of Native CSS, I don't know what the browser support is off the top of my head, but it's in all browsers. Look for ampersand class hero, looking for every hero and split. Because this is in the container query, I'm only modifying the hero when we change into this container query. When it hits this one spot and only that one spot. You could definitely split this off into two bits of code if you wanted to. But then you have to repeat the container query which is kind of annoying. I like nesting for this use case here. Because I set it up with
custom properties, overflow, grid, direction. Got to spell things right, direction. I could change this -- I'm gonna get it wrong, aren't I? I always mix up row and column. It was row that I wanted. Told you I would get it wrong. Nope. Ah, overflow thank you. Overflow grid direction. And now I probably have the wrong one again. There we go. Now they stack. The reason they're stacking, you switch something on a container or a custom property just because you want to tweak something.
That's why custom properties are so nice. They're easy to tweak. This is why you can do it with JavaScript if you wanted to. This is the beauty of custom properties. The reason this is working, this grid overflow, it's contrived with how I set it up. Anyway, it used to be column. Just the first line there, it was column. And then my grid overflow became row. They stacked. But the problem is, there's other styles I need to overwrite too. When I do that, I want to overwrite this grid auto-columns. This is what's controlling the size of the columns.
And right now, those columns, they're too small. And this is -- I guess a modifier class could work for that. But then I need a modifier class that's also inside this -- well, I can't change a class inside of a container or media query. That just doesn't work. And then again you come in with this way of figuring it out and getting it only to apply in this one thing and it would bloat your code a little bit and be kind of annoying. So, instead that have, I used the style query because
I knew they're possible. And this is why I'm so excited about them. So, a style query looks like a container query. It is @container, very important with the style query. So, it's @container and then you have a style function and put the name of your custom property. In the future, this should work
with any property value pair. Right now it only works with custom properties in the browsers that it's supported by. So, I can say that my style grid overflow direction is row. And I can come in with new styles. People that use SaaS, sort of like a mix-in a little bit. Mix-ins are -- there's a proposal that it builds on top of this idea. What this means is when I have a grid overflow
direction row, I'm gonna change a few of the other properties as well. And this becomes really, really cool because now I can conditionally switch the styling. And now my -- I'm getting the overflow direction going the other way. And I don't need no find a contrived way to do that in the media query. As long as I'm toggling that grid overflow on or off. I'm doing it inside the media queue. I could change this up here instead and then everywhere it's going to apply. So, even in this section I'm getting the scrolling up and down. It becomes a whole set of code
with two lines of CSS. You can have as much styling as you want that you're conditionally applying on or off based on the condition of the property. And things outside of layout as well, I'm only looking at layout at the moment. But I'm gonna leave this in here. And the other thing is, these are inherited properties which is really good. Because I'm not applying this directly on the container. Maybe I am. But you don't have to apply it directly on the container because custom properties are inherited, you can have it on any parent and that's gonna come in and you can toggle things at different levels without having to need more and more selectors along the way.
And one other thing that's also possible. I did the same thing with my card layout. Layout. Where I made an alternative... alternative... layout. So, again, it's only in my container query where now the title of the card is on the side instead of on top. Just toggling
that off so you can see it. They stack. And then I can toggle it on. So, I'm completely changing the layout of my card with a style query lower down that I created. And only within a container query. This would work in a media query if you wanted it to. Which is cool. I'm continually toggling on or off depending on the situation depending on what I need. Normally you have it with a class,
but can't choose it or not choose it without injecting with JavaScript when the page size changes. This, I really like this. I was very excited by this and I think it's really, really exciting. And the thing with all of this, while I think it's really, really powerful, I also think that there's probably a lot more that you can do with this. As I said, I've sort of
went through this journey myself, figuring out things from other people along the way. So, if it wasn't for Andy, I wouldn't have thought about that viewport trick and started using it in my projects. And the thing from Miriam worked really well from my column switching. But then I also figured out from what she did there how to use it in the intrinsic layout and get things to start changing there. Showing you, I'm hoping, whether you're coding a developer,
these things are possible. Would this other thing be possible as well? And trying it out and seeing if it works. That's always the cool part of this and why I love having my YouTube channel. They watch a video and reply with a better version of what I did. That's the coolest thing in the world. If you have thoughts, experiment, play, see what's possible with them. While you're doing this,
remember when these things look similar when you first start using them, when you're using them in new ways a lot of their potential starts to come through. Thank you very much. VITALY: Thanks so much, Kevin. Excellent. You must be dreaming CSS. KEVIN: More or less. VITALY: Wow. This is really impressive to see, calc -- something is moving here. That's impressive. Questions. One of them is, you know, came from me. I have to bring it up right away. Kevin, in being honest and sincere, it's a safe space here, right? What's your take on Tailwind? KEVIN: That's not nice. Don't ask me that. Can I
give me usual answer? VITALY: You can give both. The usual and not so usual. KEVIN: My usual answer is that I get why people like to, but it's not for me. My main concern -- VITALY: Did you hear that? It's like the suspense in the room. Okay. KEVIN: My main issue sometimes with CodePen is that it encourages an over-componentization of things. Because like if you're using utility classes, makes sense to use on a component. I see it a lot with beginners and new people coming in.
People using Tailwind, writing regular HTML, but using Tailwind. It's a disaster because they're repeating the same classes everywhere. It's not where you -- you're not getting an advantage from Tailwind necessarily if that situation. VITALY: Yeah. KEVIN: And then they also rely on it a bit. They don't understand CSS well enough. It's just another way to author CSS. If you understand CSS really well, you'll be better at using Tailwind. VITALY: Yeah, I think in my experience, it's been a bit strange. When you look in Tailwind, there is
an option to kind of plug style in with @apply. But maybe that's just me. But in my experience, a lot of people who are using Tailwind are extremely allergic to the notion of bringing up @apply because it goes against the very principle of Tailwind. You could have potentially both. Like nice, clean HTML and, you know, Tailwind. But in reality, it looks different. I KEVIN: Yeah. VITALY: Right? So,
I don't know if it's... yeah... look at people, I guess. I understand something. Well, but also what was really impressive just to see how far we've come in terms of nesting and this idea of actually being able to do what we used to do with SaaS. But we don't need to, again, as you mentioned, repeat container. Where does it leave SaaS, then? KEVIN: That's a really good question. I get asked that a lot. I use SaaS on my larger projects that I do. Whenever somebody asks that,
it depends on what you're using it for. Some only use for nesting, you don't need it in that case. I use loops to generate things with maps. As long as that's not in CSS, I'll continue using it, especially for bigger things. Even though the way I use it is a little bit different. Because I can rely on more modern things. But I map variables to custom properties and stuff. I can use the
custom property because there's advantages to those. Again, I think it's adjusted it. And I do think for a lot of people in different use cases, it's probably reduced the amount of people who are using it just because those features, you know, if the features are in native CSS, use the native ones, they're probably more powerful. VITALY: There is a question from Brian. Maybe you can help here. container queries and position fixed. KEVIN: Actually, that's a good -- I mentioned there's limitations with containers queries, they create a new stacking context which I'll let Josh explain tomorrow. If you don't know what stacking context it. But basically, creates problems with stack context and it's a new containing block.
For positioned stuff, you're stuck, and you can position the element. With fixed, any time someone wants something that's fixed and their having issues with the containing block, why is it in that thing that has the container? Like if it's fixed, it's a global thing. Back to top button or the NAV. The only time I've run into issues with that is because I had my header declared as a container type and had my NAV sticky. I had to re-work stuff to make it work. There are sometimes you might run into a sticking point. But if it's position fixed and something you can pull out of
the container, that is usually what I would do. VITALY: The question is do container queries make using fixed elements hard to position correctly due to the shifting origin? Any tip there is? KEVIN: Yeah. So, I think that could potentially just come down again to the fundamental understanding of what creates a containing block. So, again, that's position relative, that index, you have a new containing block and then top, bottom, left and right, not doing that to the page. But that position absolute thing is moving within the parent. Whatever. You're an ancestor that has positioning. Just being aware that if you -- if you create something as a container, that's creating container block. There are sometimes that might cause a problem. I will
say one potential fix for that, depending on -- I don't know the use case in this example, anchor positioning is gonna be really, really awesome. It just means you can have an element at the very bottom of your markup that you could position relative to another element on your page. So, that might come back to fix that. But again, it really depends on how you're using it and the situation. VITALY: Custom drop downs. KEVIN: They're coming. It's exciting. I should have mentioned that. VITALY: Of course.
KEVIN: I don't know where they're at. But we have a select. And they're making a new one. And I know there was and the on whether it should be a new one. Brad mentioned Open UI this morning. It's them that pioneered this whole thing to happen. Where it's select menu instead I think is --
VITALY: Select menu, yeah. KEVIN: It's a select that's fully styleable. You can do whatever you want with it. And it's really cool. And I'm looking forward to it actually marking usable. VITALY: We look at the things,
the custom checkbox, the custom select. And we have been using these weird hacks around kind of pseudo-element before and after and all those things. KEVIN: Yep. VITALY: And it always looked -- ah. Really? KEVIN: Yep. VITALY: That's hue we do that. I'm excited that it's really moving along. Actually in the new world of the shiny new CSS features were what are you very excited about that's high on your agenda that's not here yet? Or maybe? KEVIN: It shifts all the time. Whenever I play with something new I get excited about it. Anchor
positioning is close to the top. Which I've mentioned -- if you haven't seen it -- anybody that used tooltip libraries to line up the tooltip, that's going to be native in CSS and play with Chrome. The other thing I love here, and it's -- whether you care about browser support, scroll-driven animations. If you have used intersection to trigger animations, the stuff you
can do with just CSS on that front is so powerful and really cool. Just look up CodePen demos of it, I was using it, like, oh, I'm gonna slide an image in or I had a NAV that can change background color when you have gone far enough down. And the stuff people are coming up with now, the creative ways that you can use it. It's really, really cool. VITALY: are we done with CSS now? Something on
your wish list? KEVIN: Yeah, variable on the media queries, please. VITALY: That's really going all the way in. There were a couple of questions and just to wrap it up. Well, that was expected. When is the CSS battles coming back? KEVIN: They're coming back. It's -- I have to organize it. But, well, it depends -- if you mean where I do it by myself, I guess I could do it soon. If it's with someone else, I have to do to organize it. They added a feature to battle in real-time. I have to check that out. VITALY: What's your winning battle percentage?
KEVIN: What's my battle percentage? VITALY: Winning percentage. KEVIN: Zero. When I do CSS battles, I never try to get a high score. Because I can't do that. I don't know who is familiar with CSS battles, but you basically have to solve something in the least amount of characters as possible. Full of hacks that when I look at it, it's interesting. I try to solve them as fast as possible and don't care about how many characters I use. VITALY: And the final question that came in from JC. As material UI and the widespread use of React
and Angular, do you worry that developers might rely too heavily on those libraries and miss out on the full range of CSS features? KEVIN: That's really good question. It's something that I've thought about. And I don't have a good answer for that. I am a little bit concerned with that. And the other thing that I look at is with all of these new modern features that are coming
along, is this like things like container queries where it's a little bit, you know, having a generic ones built in doesn't really work in the same way as far as I'm concerned. Like you want it linked with the sizing of something else. I don't know. It's a bit more based on what you need. But even other things like subgrid and like it's really hard to make something using those features that's just works within these systems, I find. So, yeah. With these new features that are coming, CSS is getting more robust and more powerful, I just wonder if -- I wonder if they're gonna get integrated in or not, actually, yeah. Because even for them to bring
all of these things in there, that just makes it so much more maintenance on their own end, too. And if there's not this really big benefit for doing it for a large audience, I wouldn't be surprised if some of the things get left by the wayside a little bit. Hopefully not. But... VITALY: But the future does look bright, right? KEVIN: For CSS, I think it couldn't be brighter. I'm super-excited. VITALY: That gives us hope. Thank you so much, Kevin. KEVIN: Thank you. VITALY: Wonderful stuff. Thank you. KEVIN: Thank you. Thanks, everybody!
2024-12-21 02:26
