Sean:
Hi, and welcome to Pod Rocket. I'm Sean and joining us again on the podcast is Adam Argyle, Chrome CSS and UI Developer Relations at Google, works on the CSS Working Group, host of the GUI Challenges on YouTube, and co-host of the CSS Podcast, here to talk about how CSS has changed in 2022 and what we're looking forward to in 2023.
Welcome to the podcast.

Adam Argyle:
Thanks so much. Yo.

Sean:
So for newer listeners, I know we've had you on before, but do you mind giving us a quick rundown of who you are and what you do? And what you've been up to?

Adam Argyle:
Yeah, I'm on Chrome. I get to listen to the engineers hacking on brand-new features. I get to be in the working group, watch the new features get proposed and chatted about, and I get to be involved. And my role in that, at least personally, is to represent the wider development community.
I've been building apps for 20 years. I feel like I've got a pretty good hang on how things flow through the web and how things get built, and so I'm there representing, hopefully, the average person that makes a bunch of mistakes and holds things wrong because I hold things wrong all the time.
And apparently that's helpful in a lot of ways. And I just love building stuff. The way that things touch and animate, that's the thing I go for. Whatever it takes to make a really nice UI UX.

Sean:
Awesome. Yeah, that's fun. You get to be the guinea pig in the first one to experiment with things. You've got a lot going on there in that intro. What have you been most recently work on? Do you have any new projects?

Adam Argyle:
Yes, I just released a new website. It's like my indie social website, so it kind of looks like Twitter, kind of looks like Mastodon. Every time I look at someone's phone, they're scrolling a feed of cards and I'm like, well. How about I just make a website where I do that myself. And then I built it with a bunch of personas.
So if you visit it, it's nerdy.dev. You'll see posts from dad, which is me in my dad role. You'll see posts from Google, which will be me in my Google avatar. So I have these... It's all me, but there's multiple personas and you can consume the content that way. And anyway, it's been a really fun experiment for using latest technologies, so we're going to be talking about a lot of the stuff that I get to go deploy that on a live site and progressively enhance it. And then I also get to have fun and design something myself.
I get to own my content and I love that about it. Yeah.

Sean:
Awesome. Yeah, no, I was checking out your site before this and it looks pretty sleek. That endless feed is like the UI that a lot of things are adopting now.
So when you last came on, we talked... Well, it wasn't me. It was my colleague, Noel, but you guys chatted about the Google I/O Conference and talk The State of CSS in 2022. So I guess just to kick things off, how have you seen it, the State of CSS, change throughout the remainder of 2022?

Adam Argyle:
Yeah, that inter-op effort kicked a whole bunch of butt. They shipped, so 'they' meaning Firefox, Safari, and Chrome. They worked together, landed some features at the same time sometimes, which that takes that anxiety out. Can I use it yet? Ugh, I can't yet. But here it is. It's landed.
So that's something like Cascade Layers. Totally available now. It's all over my site. My site's built entirely on top of Cascade layers. So yeah, 2022 had a lot of success. They promised a lot of features and they delivered on over half of them. And I think they're finishing up the rest in Q1 of this year and they're already working on the 2023 effort. And how are they going to make compatibility better? What features are they all working together on?
And we're heading towards @Scope getting solidified, @Nest getting solidified. We have a View Timeline. Well yeah, they're getting solidified as well, and just some really, really exciting stuff. But Scope and Nesting and Cascade Layers specifically have changed the way CSS looks. And it's just like when ES6 came out, where it just started to look different. You're like, this JavaScript looks different. Your CSS it's starting to look a little different and I like it.
The structure feels right. We're drier. We have more power, just with a little bit of learning you got to do. There's new tools, got to figure out where they fit in your belt. And I think what we're going to see people adopt these things over the next year or two as they start new projects, as they ease themselves into these new, maybe more advanced... I put quotes in advance because I feel like stuff seems advanced when you don't understand it, but then once you get it you're like, oh, that's not so advanced anymore. No, it's not so scary looking.
Anyway, and I always do that. Cascade Layers looked really scary to me at first. I was like, this isn't helpful. I never had this problem. And now that I understand the stuff they do, I'm like, oh yeah, I'm definitely down with Cascade Layers.

Sean:
Yeah, no. That stuff seems advanced. I totally agree. When you haven't used it before, but some of them are solving a previous pain point, so it's actually making things simpler and easier in some sort of ways. And the inter-op stuff is really cool to see.
I guess my cynical persona would've thought that all of the browser implementers were racing to implement features before other people, maybe to get more adoption or something. So it's actually awesome to see that the vendors are working together on implementing those features because it's just a big user win when they do it together.

Adam Argyle:
Totally. Yeah. We all win. They just don't be as competitive or something. Yeah, it's the trade-off is very nice. I agree.

Sean:
So you mentioned that your site is using the CSS Layers. So for folks who might not have listened to our previous podcast where we had you on, do you mind going into what that helps and the pain point that solves for?

Adam Argyle:
So the way that you structure your styles before Cascade Layers was you'd have an index style file, whether it was Sass or Stylist or whatever. And in there you would have a whole bunch of imports. And those imports would start out really naive, be like, oh, just grab my variables. Oh, just grab the normalize. And then you start adding components and then you start adding new lines and comments in that file and that comment says, well, this is the chunk of these and these need to come before those. And then you have this ordering that starts to happen in that file, in that file's order is super important.
This is how things get over-written and it's very linear. It's top of the file is the weakest, things at the bottom are the strongest. And Cascade Layers removes that requirement. It gives you this ability to be like, well here. Import this file now, but put it into this layer that actually makes it weaker.
And then you're like, okay, well import this other file and put into this layer that makes it stronger. And so, that order becomes way less meaningful, and what becomes meaningful is what layers do you have? And when did you instantiate them? So at the top of my index.style sheet right now, I have... Let's see, I could actually take a look at it. I have @layer base, components. I have two layers, but I also have a lot of sublayers inside of those.
So it's like if you think about the tip of an iceberg, those are the two initial layers. So base is all the things like normalize, my themes. So I've got my light and my dark themes sincere. I have utilities, I have styles for when there's no JavaScript. So things that are just weak and foundational are all altogether. And then later, if I wanted to load something else at any other time, I could put something up into that layer even though it loads way later.
So I have a lot of flexibility and a lot of options there. And then after that one is the components layer, which again, I'd want my components to over-ride the things happening inside of a normalized and a reset and a base. So I give them a little bit more strength by promoting them in this other layer. And then inside of there, they have all these little sub-layers that are pretty much the name of the component. So when you go inspect my site, you'll see in the style side pane, components.tableofcontents.
And then all the table of content styles are right there. It might even combine with some other component styles, but probably not, just the way that I've organized it. And the styles pane, the name of the layer really helps you understand why and what is overwriting something. So we talked earlier about cascade layers being this authoring convenience, but there's a deep ugging convenience where you go look to see the style side pane is no longer this dumping ground, this long list of random stacking cascading styles.
It's become grouped and you get to see all my component stuff is at the top, because that's the layer that they're in. Underneath them, it's all the normalizing supporting styles. And then underneath it that is all the user agent is coming from the browser and it just feels right to have this organization and this naming that brings clarity to reading and authoring as well as debugging and loading.
So it has all these kind of cool benefits. You do have to name something though. People don't name it stuff, but I don't know, I find these layers fun to name and they're so innocent. I don't know.

Sean:
Very convenient to be able to have the layers reflect the structure of your app and like you said, and then when you're in the dev tools, you have the name that you gave it and you kind of can associate where that lives in your code.
Is it accurate to think of it as decoupling the cascade order from the order in which you actually import things?

Adam Argyle:
That's a great way to think of it. It gives you this ability to, on every import, just put it into a layer, so that initial order goes out the window and it now comes down to organization. Yep.

Sean:
Another CSS feature that was in the state of CSS in '22 was the :has pseudo-selector. This one really jumped out at me when I was watching that, because it's immediately convenient and you can think of a lot of ways that would be useful. Now, some of them maybe you have to see in practice for examples of like, "Oh, okay. I can see how that would help with that."
But the :has one reminds me of some of those jQuery selectors back when people were using jQuery for everything.
Yeah. How has that one turned out in 2023? Has it surpassed expectations in usage?

Adam Argyle:
That's a really, really great way to pose that question. I think it got the most usage of any of the other features that came out, rightfully because it's sort of innocent in the way that you can introduce it, whereas Cascade Layers is... Theoretically you can layer in Cascade Layers on top of an existing site. I haven't found that very many people do that especially... Well, whatever. We can get into that later.
But :has it's so much easier to toss in. You can also check for support of it. So my site for example, uses :has to... If you don't have JavaScript enabled, you can still filter all of the home feed based on the options, because I'll look to see what radio button you select and then I'll use :has to be like, "Hey webpage, do you have the CSS radio button selected? Oh, you do. Then go ahead and target the list and filter out all, set display none to anything that isn't that filter."
And so, I have this no JavaScript, easy CSS upgrade, progressively enhancement story, all using :has. And it's so easy to just add in, in little bits, or in your forms. It's really helpful in forms where pretty much any pseudo class, if you did colon invalid or colon valid, any of those little pseudo classes, they all become :has superpowers.
And so yeah, adoption is really good. I feel like one thing though gets missed really common when people are talking about it, because they call it a parent selector. A colleague, Jay, called it the family selector, which I really like, because it's more than just a parent selector. But one of the key features is that it allows you to change the subject of a selector. Until :has, you could only select the thing at the far right of your selector.
And with :has, you can select something in the middle or the beginning or the end and you can change what is the actual target of the selector in the middle of it. And anyway, it's a superpower. It's a very cool, easy upgrade and has so much potential. I think we've barely scraped the surface so far.

Sean:
Yeah, I like that way of describing, as superpower because it really unlocks a ton of capability. And I guess that leads me to ask, how do you think about introducing features that, maybe not fundamentally change CSS, but really change the kinds of things that people can do in CSS versus something that they previously would be doing in JavaScripts. Are you intentional about trying to prevent maybe feature creep or...
Yeah, I guess there are responsibilities for CS and JavaScript and do you think about a Venn diagram there?

Adam Argyle:
Yeah, that's sort of naturally for how I like to build components. I start them out as HTML, CSS, push them as far as I can go. Again, my site does this. It works with no JavaScript, but if JavaScript's enabled or CSS :has is enabled, I add and layer in these conveniences based on the capabilities of a browser. I don't expect everybody to do that, but that's the way I like to work, is how can I get away with no JavaScript is usually my initial... Even though I love JavaScript to write a ton, turns out JavaScript's pretty necessary a lot of the time. So I shoot to not have it and I shoot to not have complex @Scope rules or complex Cascade Layers or complex :has use cases.
But if I find myself in a scenario where adding one :has selector can remove a bunch of something else, I'm like, well. That's a trade-off I'm totally down to do. So yeah, I do. I try to be really conscious about being minimal as a foundation and then pick and choose UX conveniences to just doll up on top.

Sean:
That makes a ton of sense. And do you find yourself frequently disabling JavaScript and just getting a sense of how well your site works without that enabled? Or do you, at this point, kind of assume that everyone's going to be using JavaScript?

Adam Argyle:
Yeah, so when I made my site, I sent it to a friend and they were like, "Hey, it almost works with no JS." And I was like, "Oh, I totally didn't even test that. And I'm happy that it works almost."
So I was like, "Oh, I know exactly what I need to change though." I had the card. If you click the whole card, it will take you to the URL for the destination of that blog post or whatever.
And if you have JavaScript disabled, you can't click the whole card. I didn't do the anchor wrapping the whole card trick. There's accessibility stuff I didn't want to deal with there. And so instead, I just made it so that there is a link that goes to the detail there. And if JavaScript is enabled, I just hide the link. So it's like I get to deliver a really strong foundationally capable website and then trickle these different things on top.

Sean:
Nice. And that kind of speaks to how powerful some of these new CSS features are that you kind of almost accidentally have a site that's working without JavaScript, without even having to be super intentional about it from the start.

Adam Argyle:
Yep. And that is really nice. It also, though, got complex really, really fast for... If you visit the site, it feels simple. You're like, all right. It's got some filters on the site and a list of cards and then the cards go to a detail. How hard could this be?
Turns out there's a lot of complexity nested inside of things that look simple and inevitably gets somewhere kind of complex. But I like to try to keep it simple as much as possible. Yeah.

Sean:
Yeah, so I don't know if you saw, but CSS-Tricks did a survey in 2022 about CSS, and they found that 46.7% of respondents were only aware of 40% or less of the features that were covered in 2022. And so, I'm curious what your take on that is, because to me, it actually sounds quite high. Yeah. I'm curious how that matches up with your expectations for adoption of these new features?

Adam Argyle:
Yeah, there's been a lot of surprises in terms of adoption. There was also a stat on how many people are using CSS grid and it's terribly low. It's so low, you're like, do people even know it exists?
This is really bizarre. It's been around for five or six years. Why isn't it there? But then I go look at color also, and we had HSL and RGBA. Those came out in 2010. And then if you go look at the Web Almanac, which summarizes all the color usage on the web, no one's using them. The amount of people using HSL is surprisingly low, even though it's definitely superior to RGB or HEX.
So much more flexibility, yet there's no adoption. And then we could take :has, for example, which got adoption very quick. People knew what it was. It was adopted and it flew right by some of these other ones that we thought would have more adoption. So I don't really know how to solve this yet, I just know that I think a lot of people are under information overload.
CSS has come out with a lot of features in the past few years, so I totally get it if you're like I'll research it when I have time. I got a task on hand and I've been fine without these features. Maybe I'll continue. I think that's how color is, too. Everyone's like, hi, I'm fine with HEX. My relationship with color is very simple and I like it that way. So they don't need to go try color manipulations in HSL or something like that.
I would love to see more adoption. I don't really know how to encourage it more. We put out lots of articles, we do lots of videos, and we have the podcast. And I feel like we're doing the best we can to saturate the knowledge and make it as simple as possible. But it's hard. There's HTML features coming out, JavaScript features coming out... Even for me where it's kind of my entire job, I have a hard time staying on top of it.
CSS features come out all the time and I'm like, "Oh. No one told me."
And they're like, "Well, it was in the list of..."
And I'm like, "The list is huge, so how am I supposed to know?" So I feel the same way other people do, that there's just so much. You have to grab onto whatever initially intrigues you and then, I don't know, branch out as you need it. But yeah, grid low, HSL low, Cascade Layers super low, even though they're available. I don't know. I think we'll just see more adoption over time.

Sean:
I think it's a fair point. It's like that people have something that they know works. For example, Flex solved so many pain points when that came out. And whenever I have a positioning problem, Flex is the first thing that I think to use.
And it turns out that it can solve most of those problems. And I typically will find out about new CSS features when I'm debugging something or trying to Google how to do some sort of positioning or thing in CSS that my existing tool set can't solve. And then I'll see, "Oh, here's this new CSS feature. What does a browser compatibility look like?"
And then, that's when I find about a new thing, not necessarily right when it comes out in the marketing channels. The container one is another one that I was surprised at. The usage was low because that one also seems the :has pseudo-selector. Seems incredibly useful.

Adam Argyle:
Yeah, I'm glad you brought up container queries, because it's another one in the same realm. We're like we wanted it, we could easily articulate all the reasons we needed it. For many years it felt like a huge gap that was just like, why is this not here?
And then it lands and it's not deployed on very many production sites at all.
It's on my site, but in a very unique case. I was even looking at my site going, I need to add container queries. I just want to. And I was like, but I don't have a reason, so I'm not going to. And then I had a reason and I was like, yeah. My site finally has container queries. And it was the Japanese layout of my site.
So if you view it in Japanese from top to bottom, right to left, a media query that queries the width of the viewport is irrelevant. The viewport could be really wide, 1024 or above. You're like, well, the layout is now going sideways, so the width just became the height and I'm not interested in the width and I don't really want to write a height query. That feels wrong.
And so I used a container name on the body element, and then I just query the container's inline size. And the inline size does adapt when it goes sideways. And all of a sudden, I made one query that solved every language and I didn't have to worry about it. And that is cool superpowers to me.
But yeah. Why isn't this in more people's hands? I'm not sure. Even hear people like Scott Linsky on Syntax FM, he's just like, "I've wanted container queries forever and I'm still not shipping them. I don't know why."
And it's just self-reflecting on what is this feeling? I don't know what I'm feeling right now as a developer.

Sean:
The thing that jumped out about me initially, the container one, is that it fits so nicely in my mental model that I already have about how CSS works, just because it looks exactly like the media queries that we already are so used to using.
Do you think that kind of went... Having it be very similar to the way people already use media queries? Do you think that went into its design?

Adam Argyle:
Definitely. The CSS Working Group loves to not invent new things. If there's a path that is similar, we'll totally go down it. Look at the picture element. Picture element allows you to specify multiple sources. In those sources, you can pass a media query. You can't pass a container query yet. Well, we need that. We need to be able to put a container query in there now into the syntax is going to look exactly the same. So since it matched, media queries, container queries can squeeze in right where those were and just be like, well, instead of checking the whole viewport, why don't you just check this little section?
And so, I think that's good, healthy choices by the CSS Working Group. At the end of that CSS-Tricks survey, I hope I'm pronouncing this correctly, Leah Veru, W3C Technical Architecture Group member, made some predictions. And one of them was that Subgrid would grow in 2023. 2023. Curious, what do you think about that prediction? Do you agree? Disagree?
Subgrid's another one. I've done a lot of playing with it. It's another one where it seems so tricky on the surface and then once you use it, you're like, oh, this is really subtle. And it's nice. But like container queries, I feel like people might try to shove it in without... Just because they want to use something new and you just got to find those use cases. They'll find you, I think, as a lot of the scenarios with Subgrid. Subgrid is getting worked on by Microsoft on Chromium.
It's been getting code commits every couple weeks for months and months. They have a lot of tests. I know Firefox has had Subgrid for a while and it didn't see a lot of large adoption for some reason. Same with... They had Masonry. But I think as we see more tests hit the platform to test Subgrid... Subgrid is very untested, or it was. We're adding a whole bunch. Once it's reliable, it's available cross browsers, you start to see demos that implement it. I think you'll find some inspiration and use cases for yourself. You'll be like, oh, that would make that flex layout easier, because I was really stretching Flex to make it do this thing.
And you're like, oh, Subgrid. I just align this child card to the width of all the other parents' child cards and we're all happy. So yes, I would like to see Subgrid gain more adoption, but I anticipate it will follow similar to container queries in that it'll be really important when you need it, but otherwise you might not find you're reaching for it very often. Yeah.

Sean:
Yeah, it might not be the first thing that folks are thinking about until they then encounter a problem where it's the clean solution. Yeah. And I guess at this point there's a lot of different ways to do layouts. Is Flex... Do you consider Flex still to be the most popular?

Adam Argyle:
Grid has a fraction of what Flex has.

Sean:
Gotcha. Do you think that'll change in 2023? Do you think Flex is going to stay king?

Adam Argyle:
So, I can look at usage of me and my peers of how we do layout now, which is almost entirely Grid. And it's not by choice. It's not like we intended to go Grid more. It's just, as I've used Grid more and more and more, it so succinctly solves many of the problems that took a tricky Flexbox layout. And so, I use Flexbox layouts still. It's not like I've gone one or the other, but I do find I use a lot more Grid.
And so, maybe what we're noticing in terms of trends here, is that the corpus of the internet over 20 years, or even just the last 10, has really solidified a lot of patterns. And I think we're going to see that it's slow to get out of those patterns and into the new ones. I anticipate Grid will grow and I anticipate it will surpass it. It has too much use in macro layouts and micro layouts where Flex, I think, really excels at micro layouts.
I don't know. Flex can do all the big layouts, too, so I just think judging how some of these other things have slowly progressed, we're probably going to look at a pretty slow adoption climb for some of these other things too. It's almost like the heyday for modern CSS adoption with CSS3. And now that we're past it, they're incremental changes and not quite as massive.
But I don't know. That's so easy to argue, that I think CSS is changing so drastically. We're on the cusp of the most massive shift it's ever had. So maybe that scares people away instead of bringing them in. I'm not totally sure.

Sean:
Yeah, interesting. Yeah, maybe seeing so much change maybe intimidates people. There's too much to learn. But yeah, no. I think I agree that it seems like something that'll just be a gradual change over time. Here at LogRocket, we use a ton of Flex. I think it's primarily because most of the ways that we want to display lists, end up being 1D, which Flex does naturally so well. Just one column. It's so easy to use Flex for that instead of Grid.
But before Flex people were hacking layouts together with tables... And I don't know when that was, maybe the early 2000s, a little bit before I was involved in web development.
But I think maybe it just takes time for people to break those habits of using layouts for more than what they were designed for.

Adam Argyle:
Yeah, I think breaking habits is a really great way to describe it. I've described it as people are just accustomed to working. I was mentioning color. They're just used to HEX. They're like, I've never felt like HEX was broken. And people give me HEX. So that's just how I work. I get given it and then I put it in the code and that's how I work with color. And it's like I've been studying color like mad for three years and I have a very different relationship with color. And I'm infatuated with it. It has all these superpowers and all these use cases. And if you're building a design system, it's really powerful to not work inside of HSL or HEX or RGB, but to try one of these new spaces that are about to come out.
Then yeah, I think we'll see a lot of change in color, as well, especially as displays get better. Everyone's getting better displays on their desktops. They've had them in their pocket for years. We want to see those juicy colors come through in our gradients, in our candy-coated buttons. Those things should be really glossy and juicy. Let's maximize the color there.

Sean:
Yeah. No, for the color spaces, the perception where... Is that what they're called? Perception-Based color spaces, where the gradient is based on not just the pure RGB mathematically, evenly spaced colors, but actually the way that humans see the differences in color?

Adam Argyle:
Yeah. Back in the forties, they did a whole bunch of tests on actual humans looking to see what grays they could see, what grays they thought were darker than others. And so, you have a human driven color space that's really powerful for all sorts of things that LCH can do.
Yeah, it has perceptually linear light. So lightness goes from zero to a hundred percent in the way that you're... Like have you ever done this in HSL where you're like, "I want a really dark gray."
And so, you're like, "Oh, okay. 5% lightness, really dark."
And you're like, "Oh, wow. It's really dark."
And then you add 10% and you're like, "Hey, that's not that much lighter."
And then meanwhile you want to make a light color, like a really light gray, and you do HSL lightness, 98%. It's like barely not white, but for some reason those little edges there really change a lot. So you had dark that needs a lot of change to be visual for you to notice it. And then lightness, little tiny nudges go a long way. And you're like, "This color space is lightness, feels a little hard to work in sometimes."
And so, when you're inside of LCH, if you bump 5% in either direction, it is a noticeable amount of 5%. It's consistent in all hues also, whereas HSL can do wild stuff depending on the hue. And then another added benefit of LCH is that it can use HD colors. So it's not just good for manipulation, it can also reach into the better pixels and the brighter pixels of a screen. It's like a win-win.

Sean:
Of course, monitors have made so much improvement inside the color spaces that they can display. So it's only natural that we would want to tap into that with the CSS colors that are available. And it was just cool to see that the color... I didn't know that the human eye worked that way, in terms of perceiving colors. Kind of reminds me of sound. I think the decibel scale is logarithmic, because a sound needs to get much louder in order for us to perceive it that way.
But no, I'm asking about why do you think these things aren't being used? And I hadn't heard of them until I watched this, the CSS in 2022 Talk. But no, it's good. Good that I'm hearing about them now.

Adam Argyle:
Yeah, and Leah Veru, who you mentioned earlier, I think at the end of that post also was like color revolution is coming. She's also one of the main spec editors for color four and five, which bring the new color spaces, better gradients, color functions like color mix and stuff like that. It's an exciting time. I think she also said Nesting is going to be big in 2023, and I agree.

Sean:
Hopefully. Yeah, she's probably pretty tapped into the way people are using CSS. I think that probably will be accurate. And then another thing is the CSS in JS Libraries. Do you use one of those on your site?

Adam Argyle:
My site does not, but I've used many of them. And I have a talk I want to give in 2023, which is about how to use Cascade Layers in CSS and JS. The reason is they're like a match made in heaven. CSS and JS has tons of asynchronous, lazy loaded styles and when they lazy load, they just get plopped right into the page and then they have to compete with the whole stacking order and order of appearance. Just the whole nine gets really messy. Why not just take that chunk and put it into a layer?
So you put it into the page wherever you want, but it actually goes way up into a weaker layer up in the stack of your styles. And that is super cool. It would reduce the amount of specificity that you need to put inside of your selectors, which it's a benefit of CSS and JS already is being that minimal selector.
So yeah, I could totally see a relationship growing with some of these new features and CSS and JS. Same with Scope. @Scope is the same deal. So you could dynamically append or asynchronously append the whole chunk of styles and do a layer, and inside of that layer use @Scope to tightly contain those selectors and those styles to adjust your component.
We're in this. That's what I mean. We're entering into a whole brand-new world, and you have container queries. The whole component model is getting a lot of support in 2023, and I think we're going to see new patterns, new confidence show up. That's going to be great.

Sean:
Yeah. Is the scope thing something that's native to CSS? I think I've seen something similar in a View Components, for example, where you can have the CSS of a View Component that only affects those styles, only affect the HTML of that component. Is that something that's just built into CSS?

Adam Argyle:
Yeah, so you could keep using CSS modules if you want, so they don't have to name things. But @Scope has a superpower which is, not only does it trap the scope of something from your class selector down, you can tell it where to stop as it goes down, which is not something any other... View can't do that. They could try, but I don't really think they could. A clever naming strategy can't get you out of the fact that your styles cascade and with @Scope you can stop the cascade and be like, no. All of these colors that I changed, these fonts that I changed, trap them one level deep in this node tree. And that's it.
And that would be like, what they call, the @Scope donut, where it has an outer, you can take some bites of the donut and then the middle of the donut's gone. You have styles that can behave in a very, very similar way.

Sean:
That's a very helpful analogy. Yeah, the donut, it's only the outer ring is affected by it. That's pretty cool.
Yeah. So I guess I kind of asked you if you agreed with some of those predictions for CSS in 2023. I'm curious, did you have any others?

Adam Argyle:
I think we're not done seeing interesting new features yet. CSS Mixins, it has headcount right now or people are going to spec it out and try to prototype what CSS Mixins could be. We have view transitions which are let the browser flip your animations. That one's really sweet. Vue Transitions... We also have View Timeline where the scroll and the percentage of scroll that someone's at can power an animation. And then that same feature also lets you know when something comes in and goes out and you have all this CSS power to describe the animation out and animation in of stuff. What else is there?
So we got... Yeah. Mixins, View Transitions, View Timeline. Nesting is behind a flag in Chrome. They're trying to push it out the door, because Safari already has an implementation, too. So we're going to see that in 2023, I hope. Color stuff is about...
Not only is all the stuff from 2022 about to land, the plan for the next set is just not stopping. There's full steam forward. They really want you to feel that the web has your back when it comes to building something and empowering you as a developer, to build a custom experience.

Sean:
No, I'm excited for it. I guess for people who are listening, I don't know if any people have been inspired by this and to stay more up to date with new CSS features. I guess how would you recommend folks stay tuned into this sort of thing?

Adam Argyle:
Nice. That's a great question. So if you want to go... It's not even hardcore mode. I'm using air quotes, hardcore mode, but you can go straight to the source of Chrome Status. So, there's a website called Chrome Status and you can go subscribe to the CSS changes and the JavaScript updates. And what you'll do is, you'll start getting emails as soon as one of the engineers on Chrome says, "Hey, I've been working on this prototype and it's ready for the public to try and canary."
And you'll get an email and be like, new feature. Just the other day, we had new Relative Units land in the browser, at least in Chrome, which was the Relative X Unit. We had the Relative IC Unit, we had the Relative Line Height Unit. And these things I didn't even know were getting worked on, but I got that email and was like, a brand-new thing is available for me to go play with.
And so, that's how I stay on top of these things. There's also the web.dev website. web.dev will share stable new features for you, so it's exclusively stable. And if you go to developers.chrome.com, those are experimental features. So you could go to Chrome Status for an email right away. You could RSS subscribe to Chrome Developers for experimental features as they come out. You could RSS subscribe to web.dev, get stable features as they come out. And then, of course, all the normal suspects after that.
You could subscribe to my RSS, you could go to Twitter, you could go to... I don't know at that point it's all in the air, but that's where I source my stuff and how I get it the fastest is that way.

Sean:
Makes sense. Yeah. So there's a lot of different channels to continue to hear about this sort of thing.
And I got to ask. You were number three on People in CSS lists this past year. How did you feel about that? That's awesome.

Adam Argyle:
I was so surprised. I was definitely really proud. I couldn't believe it. I still feel... I don't know how old you are, but the only reason it is relevant is I remember I was 26 and I was like, "I still feel 18."
And then I turned 30 and I was like, "I still feel 18."
Here I am, number three in the CSS list of influencers, and I'm like, "I'm still just a regular person writing code." I don't feel super. I mess up stuff all the time. So yeah, I was very pleasantly surprised. I was like, "Oh wow. It's working. They like the way I talk. That's nice.

Sean:
No. But yeah, that's great. And I think it's pretty clear that you're doing a lot for the community, so we appreciate you.
And before we wrap, is there anything you want to plug or where can folks find you online?

Adam Argyle:
Sure, yeah. Subscribe to my RSS, my new site, nerdy.dev. You'll get all sorts of... I'm trying a thing. I guess it's micro blogging, but they're not quite status updates you'd get on Twitter, although there are those, as well. Really, really short ones.
But my blog posts, I'm trying to keep them five minutes or less. It's like powerful demos, succinctly writing them. My natural voice. Whereas when I write for Google, I have editors that review it and it has to sound like we all talk the same and stuff like that. So it's like my little space to go be me.
And so, if that sounds interesting to you, I'd say go subscribe to that RSS.

Sean:
Awesome. Yeah. Well, it's been great chatting. Thanks for coming on and we'll stay tuned to what happens with CSS features in 2023.

Adam Argyle:
Rad. All right, well cool. Thanks so much.

Sean:
Thanks. See ya.