Why CSS is Now the Fastest-Moving Space in Web Development (with Una Kravets)

Why CSS is Now the Fastest-Moving Space in Web Development (with Una Kravets)


While everyone's talking about AI disrupting development, Una Kravets from Google Chrome reveals a surprising twist: CSS has quietly become the fastest-evolving part of web development. In this conversation, Una breaks down how features that required months of JavaScript engineering are now landing as native platform capabilities. Think customizable dropdowns, anchor positioning, and scroll-driven animations. She shares insights from working directly with Chromium engineers and explains why senior developer expertise is becoming more valuable than ever, even as AI lowers the barrier to building applications.
Una walks through her process for identifying platform gaps and working with standards bodies like Open UI. She also tackles the unique challenge of scaling web platform knowledge in an AI-driven development landscape, sharing her mixed feelings about AI's current applications. From her success building Chrome extensions with Gemini to her frustration with chat-based customer service, Una argues for using AI where it makes sense while maintaining the human elements that make the web engaging. Whether you're skeptical about AI's role in development or curious about the cutting-edge of CSS, this conversation offers a grounded yet forward-thinking perspective on the future of web development.


Our Fantastic Guest
Una Kravets
Una Kravets leads the Web UI Developer Relations Team at Google Chrome with a mission to make the web platform easier to build on and more powerful. She hosts the CSS Podcast and has spoken at over 100 conferences around the world helping folks build better web interfaces. When Una isn't online, she loves to craft and recently became a mom.

X
Bluesky
Website


Links and Resources
Emil Kowalski's React motion course animations.dev
Google's web development guidance and feature announcements
Open UI Community Group
CSS Working Group GitHub
Web Platform Tests

Thank you very much for listening!

We are also pretty much on all social media platforms, so make sure to like and subscribe!

Homepage - https://www.weeklybrew.dev/

BlueSky - https://bsky.app/profile/weeklybrew.dev
Instagram - https://www.instagram.com/weeklydevsbrew/
TikTok - https://www.tiktok.com/@weeklybrew.dev
YouTube - https://www.youtube.com/@theweeklydevsbrew
LinkedIn - https://linkedin.com/company/the-weekly-dev-s-brew

Transcript

1:00:00

Welcome everyone to another episode of the Weekly Dev's Brew. I'm super excited to sit here today with Una. With Una. Yes. We are going to talk about interaction patterns today, besides probably a lot of other stuff. And before this podcast, you mentioned that you've learned a little bit and researched a little bit and thinking about interaction pattern that we apply these days to the in the web, but also how they're going to change, probably with things like AI and those things. So what are your thoughts so far? Okay. An area that I have worked in for the past few years has been CSS, HTML, JavaScript, things that are core to the platform, right? That help you build UIs, make it easier to build these engaging web experiences. But right now, we're at this interesting point where this whole definition of what a web developer is, is changing. And we have these AI tools that are using LLMs that are searching the internet for what other people are doing to then build these UIs and make all these decisions for you. And I find that this is really interesting because you don't have to have web development experience to build web applications. And 90% of what I see that's coming out of these LLMs is web stuff that's coming out of these AI tools. So that is interesting to me. And I think that there are these opportunities and these gaps that aren't really filled that kind of exist, especially when you're letting a tool make the decisions for you that doesn't really have all of the right inputs. And it leaves all these opportunities for what happens in between stages. How do you improve a user experience? Like morphing animations is one thing that I'm seeing a lot of animating between page views within page views, like thinking about having like the right sort of easing between animations. And so I've been like looking a lot at what exists out there, these pattern libraries that like AI tools are using, also developers are using. And I'm also taking this great online class from Emil Kowalski called animations.dev. And that's been really interesting because it kind of is giving me this viewpoint of, like perfecting animations, like the small things. And that's an area that I feel like I'm not really good at. So I'm like immersing myself in it right now because I want to improve. One thing that you mentioned, I think is very interesting. And you said that the definition of web development is kind of changing right now. And I think this was already like never really defined topic to begin with, because we had always these floating rules of like a JavaScript developer, UX developer, web developer, and they're always like kind of like tangent. And they're like, if it's like a Venn diagram, they're like all have those overlaps, but there's also like a certain distinction. So I'm really curious to see or hear your thoughts on like, what do you, how do you, how would you define web development these days? I think that this is an interesting question, right? Especially with AI tools, because you don't even have to have any development experience. You don't have to be a UI developer or, you know, full stack developer, or even a UI designer. Like you can just open a tool and I don't know if we want to like get into specifics, but you can just open a tool, you can write a prompt, you could have this tool generate an entire application and UI for you. And then your job as a developer is essentially to debug, find the gaps. That's where like the, I think development expertise still comes into play because no AI tool is really perfect. We'll say perfect, but also like once you go beyond like the zero prototype, that's where the challenges start to pop up. So that's like where your development experience and skills are pretty critical. But what I've been seeing lately is people who don't come from this world that might come from the music industry or come from like the beauty industry or something else, be able to build apps or sites or things that are tools for themselves or for their friends. And like, that's, that's a part of the AI space that I've been having a lot of fun with. It's just like building tools for myself and my friends. So I think that that's been interesting, but like not necessarily for production yet. Although I could definitely see that space changing a lot right now. I'm always fascinated by how the commodity of those things change. Like, oh, you have, I don't know, you want like a, I don't know, like poker app, but it is like$5 on the Play Store. So you can just dump something at V0 or something and get an app to play with your friends. I like the barrier of entry got so much lower in a way. The barrier to entry, at least for building an application is definitely changing. I don't think that we're going to necessarily see a lot of folks who don't have development experience be successful in like launching a bunch of production products. I also agree with that. Because that is, I actually think senior level expertise is more valuable than ever, because the thing that AI struggles with the most is a finesse, which is like this area that I'm kind of interested in right now. Making your application look actually different than every AI app out there. And then B debugging, like when you actually are trying to build a complex feature, that's where it seems to get stuck and run in circles because the answers aren't already out there. Right? So if you're working on like some kind of unique value prop or like a unique technical challenge, that's where you're going to need experience. Yeah. And I think AI is also a great learning tool for people who have less experience. Because you can use it to explain a code base. You can use it to like understand how to make certain tech, like what direction you should go. But yeah, there are limitations. And that's, I think on this podcast, I said this also before, but I was always hoping for that. But so far, everyone I talked to is more like, it's frustrating for junior developers, because they don't understand what the code generates. And they're, they're still lacking this level of like, ambition, maybe in a sense, but also like, just like expert periods to like, okay, I need to understand what the code does. And how do I bridge this gap? How do I approach it? So, so far, most of what I heard from the industry, I like, as a position in developer advocacy, it's a little bit different. Oh, you probably know. But so far, everything, I was also very excited. I thought like, hey, this would be a great tool for me to finally learn Rust, which I've on my to do list for like, probably three years at this point. Or I still have a Vim Motions book, like literally laying in front of me here. Um, like, I kind of agree with you, right? I used to come from that perspective of, this is horrible for juniors, they're never going to learn how to code. But I disagree with that now, after having played with AI tools a lot more in spaces that I have no experience in. So like, for example, I recently built an internal Chrome extension that does a task that was frustrating me for years. And like, the task is basically, whenever we do slide decks for Google IO, we have to use Google drive, Google slides. To do syntax highlighting for Google slides, we have to go into this tool that somebody else built in a separate tab, and then take my code from the Google slide deck and paste it over and then change some values, and then go back to the slide deck and find your slide again and paste it like all of these just like annoying steps. So I was able to quite quickly use Gemini, which is just because that was the, you know, the tool that we have internally, lots of tools. But the most recent version is actually very, very good. I was able to build this Chrome extension and then ask the AI, like, how do I install it? What are the steps that I need to do next, like, kind of learn about how to even build and install and test Chrome extensions by asking those questions. So now I have more than zero knowledge about Chrome extensions, but zero I had none before. I kind of hope and I had Mark Texan here on the podcast before and he described LLM to AI tools kind of like back in the days when people had to learn how to Google. I hope it's kind of like that, where we're at this phase right now where it's like, yes, we have to find good patterns how to utilize this tool and like, yes, getting from not working to working should always be step number one, but understanding why something is working should be step number two, maybe step number three. Yes. Like, I think another thing is this discrepancy now that I feel as a developer relations engineer versus like a user of these tools where I think the writing and instruction is going to be more important than ever to make that very clear. But people like authors, developers are going to be reading less than ever because like another thing that I did literally yesterday, I wanted to build a polyfill for something and then I wanted to test against a platform test and the docs on a platform tester just kind of long. So I installed the repo and then I just asked Gemini to set it up for me. So I used like NBS code Klein and then it does like the auto acting for you. And I just had it set up the repo without having to like go through and read the instructions. And then you can ask it questions against the readme. So I could ask like, how do I run this in Firefox? How do I run this with a injected script? And like, that's what I mean by you can use these AI tools to improve the speed of your workflow and also to like learn how to do something, like how to test against a platform test. When you said developers are going to read less, I thought you meant about source code because I'm fairly sure that the shift from like writing code to reading code is going to be a lot more going towards reading code over the next few years. Maybe. It's just such an interesting position that we're in right now, right? It kind of feels like being a kid in a, how do you say, like candy store, right? Kind of like, because there are all these opportunities right now. Like I think as we as developers have like the creativity to see now, now that we've like proven, okay, those are viable tools that we, that actually deliver benefit for us in our daily work. There are all these possibilities. And it's like, okay, what is going to be like actually happening? Right. And what's going to seem useful? Yes. I think that there's times where I don't think AI is the best tool. Like for example, writing blog posts, I think you get a lot of derivative types of phrasing. You, at least in my line of work, like I usually am writing about something that is new and there's no documentation yet or like no one else has written about it yet. So like, that's not going to work for me, right? If I try to use AI for that, it's just going to hallucinate and make stuff up. But I think it's really great for like little tools for yourself. It's great for understanding code bases too. Just asking a question as you go. I think that it's great for improving the speed and efficiency of stuff that you already know how to do. Just like asking it to architect out something that you already can kind of go through and sanity check. So I think that those are places where it shines. And I too kind of like have this weird mixed feeling about it where one thing I did notice is that when I went on leave, I was, I just had a baby. We were just talking a little bit. I went on leave in September. I came back in May and the AI tooling between September and May just completely changed. It got so much better. Yes. One thing where you said like you don't like AI for writing. One thing where I disagree with that is for internal writing. I had to do like a lot of executive summaries recently. And like for that level, like the information matter, not the way it's written. So I'm like, okay, I don't need to spend like two hours writing something together when I already have like all the key bullet points that need to be mentioned. Well, that's summarizing and AI is very good at summarizing. Yes. If you have notes. Yes. Yes. And you need to put in the work of like, okay, what are the important points and stuff? But that was one thing where I was like, okay, I can get this out of the door within like the next 30 minutes instead of me sitting down. And also like writing as a non-native speaker takes me a little longer. So yes, this is another, like my parents are Ukrainian and they're also non-native speakers. And my mom, for example, has a lot of, I think, anxiety in how she writes emails specifically, and will sometimes have me like proofread just like quickly time around. I feel like I really want her to use these AI tools just to help her more confident in sending this message. And that's a great use case for it, in my opinion. Yeah, agree. Okay. This is, I love this conversation. But let's circle back a little bit. You mentioned that you dove into animations and like the finesse of it. Like, what do you do? Are we talking about like the last 20% of like an a 100% animation or like, what does, what does that look like? Yeah. So I've kind of been thinking about how do you make the web feel better? Like feel more native? There's something about, it's, this is a big topic. Okay. So one interesting thing is like on your mobile device, you have these physical metaphors, right? Pressing, swiping, like gestures, physics, like there's something physical there that you as a user respond to. We don't see that as much on the web, at least on desktop and definitely not on mobile web. So like, yeah, capabilities are still there. It's the same form factor for that device. But we see it less. I've been looking at comparing like mobile websites to their mobile app counter parts, trying to figure out what the gap is and why that exists. And if there's platform features that we need to ship to make it easier to make things feel smoother. But I also have noticed that there's really some unique capabilities that we have on desktop, like hovering, like cursors, things like that, that we're also not really taking advantage of as the average developer for making your site feel more app-like, even though it's on the desktop. And so I've been kind of like digging into that a little bit. As I mentioned, I'm taking this course by Emil, who teaches React motion, frame of motion, motion for React, I think is what it's called now. And like that to me is really interesting to see the choices that are being made here. Like some of these patterns are things that were definitely a gap on the platform that I think now we're starting to ship. Of course, it takes time for things to go across browser, like animating things in and out, right? Like entry next effects is like a new platform feature. Morphing is something that I see here that's also like highlighted in the course as a way to make things feel a lot more fluid, which I agree. Because like one thing that is a little bit jarring about using any digital experience is like moving from one place to another. We don't have like the same kind of analogy of like walking from one room to another where you know where you're coming from and going. It just kind of changes. But now we have these new capabilities like view transitions that really help more like either screen views or we're working on like scoped view transitions so that it doesn't freeze like the rest of the page where you can now sort of transition these like micro interactions. So I've been looking into that a bit more and how we can make it easier to create these like fluid experiences. And then like I know the AI thing is like seems like a side, but I'm thinking about that now is this is the way to scale these best practices today because that's where developers are moving to. So yeah, that's kind of where I'm leaning in this like interaction space. Okay, I was like probably like 15 questions now, but I think I think the one that I want to ask, um, because usually the the approach that I see so far most framework take to like teach best practices to LLM and chat applications is building an MCP. So that's what the Angular team has been doing. I see Tailwind, I think has been doing this recently. And I think today, the by the time the podcast goes live, not today, Chakra UI has published an MCP to make sure that they use the latest component that they publish and those kind of things. So do you see the approach from your end as like Chrome web platform would be to ship like a platform MCP? Or what are you? What are your thoughts on this? Interesting question. I don't know. I don't have the answer for that right now. But there's a couple of different ideas that I've been toying with. And one of them is not from Chrome, but I think a better place to do this would be a standards body or a community group like Open UI. So I've been working with the Open UI community group to possibly ship a set of patterns that would be like default, like low level accessible patterns for things like a login form or alerts like dialogues, things like that, that use these native components that could be scaled, like maybe, I don't know, like Radix or shadcn or whatever these component libraries libraries are that maybe they would use these underlying patterns and have this sort of knowledge or approval from like a web standards body, right? So that's an idea. I think that that would be interesting just like an accessibility perspective. Yeah. And there's this also, you know, there's MCP, but there's also like cursor rules and like these different AI rules files that let you as an author specify how you want things to be built and like specific direction that you want the AI to take as it starts to generate your front end. So I think that's like another direction that's possible. There's always this really unique challenge from my end of like activating new platform features, which is browser support. So what do you do then? Like we're kind of stuck waiting sometimes for cross browser implementations. Yep. There is this baseline initiative now that sort of documents availability cross browser and when things ship to all browsers and then there's like widely available. So I'm thinking about like how do we integrate that, you know, as people are building on the web. It's a unique web problem because on native OSs you have version locks, right? Where as a person updates you can support a certain set of features. But yeah, I think like MCP is interesting. I think rules files are interesting. I think even just like solid documentation so that agents could understand what their reading is interesting. Marking things up in a specific way for AI to better understand is interesting. Like do we need to ship web platform features for that? Yeah. We have a lot of options. I'm wondering, can you just knock on the door of the Gemini team and ask them those things? Like what would be the best way to teach an LLM like Gemini those things? Or is this more difficult? And I'm intentionally asking because like it's a big company and those things are never as easy as it seems. Unfortunately not. And this is like something that we've thought about too. Like, oh, can we provide these core accessible like components that, you know, Gemini could use. But the team essentially said that they don't weight certain resources. Yeah. Just like from the nature of it. And I understand that too. Yeah. So we couldn't really go down that route. But what we could do is try to get more developers and like activate it that way, get folks to use it. And then the weighting should naturally increase and Yeah. Um, kind of have it go more from like a program perspective, especially if you're working with like web platform and standards bodies. Yeah. Yeah. Yeah. That makes sense. And, and that's also the thing on the other hand, like this space is so fast moving. Like I think the latest is Gemini 2.5 Pro. I wouldn't bet $5 on the fact that there isn't a Gemini 2.6 in two weeks. So it's just like, I'm not saying there is, and I don't know the details and stuff. I'm just always surprised by how fast moving the space is right now. And it's so hard to keep up. It's so difficult to commit on like certain things. So, um, totally get that. And if you want to talk about fast moving spaces, CSS is probably the fastest moving, uh, space web development right now outside of like these AI tools. Okay. That was very catchy. I should probably make this the title of the episode. Okay. I'm super curious now. Why? Because, and again, on shame on me, but I'm also okay admitting it. I should spend a lot more time or investing a lot more time properly learning CSS and spending a lot more time in that space. So I'm partially oblivious. Um, but why do you think it's the fastest moving space? Because usually like, I mean, there, there's still this running joke that there's a new JavaScript framework each week, which is not the case probably anymore since 2019, but this joke is still floating around. It's funny because I feel like there's a new CSS feature each week. That is, um, I think that we're in a really interesting space right now where we've been shipping not only platform gaps, but also these features that create these new capabilities for developers. So for example, we talked about V transitions, couldn't really do that before in the platform. Um, now we're shipping things like customizable select. You can actually style a dropdown menu finally after 20 years. Um, that's something that I think is really exciting. Uh, now we're working on, um, like size attribute and select multiple. Hopefully next will be combo box. That's a whole can of worms. So TBD, but that's something that open UI has been discussing for a while. Um, with customizable select, we shipped native anchor positioning. So you don't need to have a third party library to anchor elements together anymore and to animate them between, um, positions is, um, something that you can do. I think that it could be improved. We also have an engineer working on new container queries for the anchored position so that when an element moves into another position, you can restyle it. So like, if you have like an arrow, you can move it around. Uh, we also have new container queries for scroll state. So if something is snapped or if it's sticky, there's a CSS hook to style it, uh, which is big, I think, um, in the scroll space too, we've got scroll driven animations, which are new. So you don't need to have these heavy libraries and like all of this, like eliminates need for like different observers, right? Which are heavy JavaScript. So you don't need, um, intersection observers. You don't need resize observers for a lot of these things. Uh, we have container queries that landed and is now widely available. We have new carousel APIs, which let you build CSS carousels, but essentially a carousel is just like a fancy scroller. So you get these new affordances for navigating through your scroller, like these previous next buttons and scroll markers. And, um, what we'll ship probably right before this episode is scroll target group, uh, which I just wrote an article about where you can make a scroll spy with just two lines of CSS, where you're able to specify like that. I want these links, these anchor links to be, uh, markers for different points in my UI. Um, so you can create a scroll spy that way. It's basically like making a carousel, like your whole page is a carousel. And then there's, um, the ability to style the active target. So target current is the pseudo class there. I feel like I can just keep going and going, but there's a lot of new CSS and UI capabilities. Um, there's like declarative dialogues. There's, there's a bunch of stuff. That is super exciting. And I, one thing I'm a little bit concerned, or I would like to hear your opinion on, do you feel like those things might landed a little too late because there is already a JavaScript solution for this so that like adoption would just be harder, kind of like, like if I compare it to apps, usually the first app that brings a feature out wins usually like we've seen this with WhatsApp and that's like a little bit like very black and white and like, kind of like bring this example to like a different level. But are you concerned that the trade-offs options are for developers, at least not apparent enough that they would consider those choices, even though there are viable options now? Well, I think that you bring up a great point and this is something that comes up internally a lot. Like why are we building these features if you could theoretically use a JavaScript library? Um, from my like perspective as someone who cares about the health of the platform, these are real platform gaps and these are core platform features and we shouldn't have to rely on some third-party library or tool to be able to build these into the core platform, right? Yeah. We've seen libraries come and go. We've seen like Bootstrap and Mood tools. We've seen these things kind of fade in and out of fashion. Um, I think that the platform, not I think, the platform has never faded out of fashion. The capabilities of the platform are just growing and becoming more powerful. I think that that's really important to make it the place that developers want to build their, their stuff, their application, their site. So I, I think this is necessary. I'm hoping that we make it either easier to build it natively or that these tools can integrate the native feature because there are hooks that make it more performant. There are things that make it a little bit more reliable too, because you don't need like a specific solution for react versus angular. You could just have the native solution. And so I think that there are a lot of benefits of resolving these gaps from a platform level. And I just hope that we can scale it. Okay. Usually the platform features like that. I haven't used a new dialogue, but I would assume that things like accessibility are considered properly because accessibility for dialogues is just such a pain in the ass. Yeah. Um, yeah. Dialogue is an interesting one because all of these UI libraries use or have dialogues like they're shipping modal dialogues, but very few of them actually use the dialogue component, which I'm really curious to dig into why, because dialogue does have top layer support, which you can't do in JavaScript. You can't access the top layer without using either a dialogue or a popover. So that's one nice thing you have to worry about like Z index management. That also means that you don't need like react portals to portal through or tunnel through like the top of your app. You can just use the native thing. There's a lot of benefits to like these core features. One thing that was missing until recently was the ability to declaratively trigger dialogues. Like now we have command invokers and we have, um, light dismiss, uh, with closed by equals any just with dialogues as an attribute. So you don't have to like add logic to click test and see if you're inside of your dialogue or outside of it. There's a lot of scripting that you could just get rid of and use the native thing. I'm thinking browser support might be one, uh, for some of these newer features. Could be. That's, that is a big thing. Yeah. How is that in those standard bodies? Like I know I talked to Daniel from the TC 39 and for them, they have like their process where it's like, it's basically not fully accepted before it's implemented by more or less every major browser. How is that for CSS and other standard bodies? Like what is the process? Yeah. Yeah. Yeah. So usually we'll, we'll a gather research. Like what is the gap? Then propose an explainer or open some issues and talk about it in the groups. Sometimes we'll do a prototype first to test the feature. And then based on that, a lot more discussion can happen. And there's a draft spec that's written that outlines what the feature looks like. And then there's a lot of discussion and it usually takes a long time. And in the process, the prototype is updated and I have to go and update all my demos. And then eventually there's resolution. The shape of the API is sort of hardened. Browsers like across the board and other invited experts weigh in. That's sort of like how the CSS area works. Like there's resolution, it's promoted. There's a whole series of like editors draft and like how it kind of moves into a candidate recommendation status. That is a CSS working group. So it's a web standards working group. There's also community groups. Like I mentioned, open UI, which anyone can join. You don't have to join through your company. And the process there is, it's a lot more discussion. We have folks that are accessibility experts. We have folks who come from like the design system space. We have folks that are UI developers. And this is where a lot of conversation is started for things that kind of live between CSS and HTML. Because HTML is a what working group. And so they have a process too. And meetings and like resolutions and things for the HTML spec. So open UI will have a lot of this pre-discussion, feedback research, and then it's graduated to either CSS working group or the what working group. Gotcha. So hopefully we see cross browser support and shipping. There's also a program called Interop, where we all come together, all the major browser vendors and kind of make a decision around what we want to focus on as like a wider community and ship. And it started as this effort to like identify bugs and gaps. And now it's sort of included newer features that we want to see because there's a wide developer need for it or they're very popular features. So that's definitely grown. And it's great to see folks come together there. That's an interesting point. How do our features or ideas brought up in such a forum? Because like, I feel like to some extent, it's hard to identify, okay, this is something that exists that is commonly used, but this is fully powered by JavaScript libraries right now that should probably be transitioned into the platform. So how is that identification and proposal process then? Anyone can open an issue. So anyone can go to the CSS working group, GitHub or the Open UI GitHub and open an issue and describe their problem. The more detailed, the better. If you have test cases like gaps, that's best. Usually this comes from, I'm trying to do something and I can't do it. Mm-hmm. Uh, this is a, this is a gap. We need this feature in the platform. Then it'll be aligned to a spec and it's usually labeled and like whether it's, I don't know, layout or whether it's, uh, anchor. There's like these different specs. Mm-hmm. Um, you know, I'm sure if you've ever gone and looked at CSS working group drafts, they're, they're long. Yes. They're heavy. Uh, maybe you could use AI to help you read the draft, uh, spec or. Yeah. That would be helpful. Yeah. I think it could help summarize it. Actually, I think it's a good use case. Um, but yeah, that's, that's how you do it. And anyone can participate in that process. Another great way to participate in web standards is by taking the state of surveys, like state of CSS, state of HTML, state of JavaScript, because we look at that, um, and other browser vendors and folks who are building for the web platform, look at the results of those to help us see where developers are struggling, what they're excited about, um, what the gaps are. Do you, do you have like a concrete example of something that transitioned or like that was a conclusion out of one of those? Because I'm, I usually participate in the JavaScript one and I try now to think back. I'm trying to like match my mental model. I have been way more involved in the CSS and HTML space. So I can't really speak to JavaScript, but, um, a lot of the architectural work that has shipped in CSS, like CSS nesting right now, we're looking at functions and mixins. Um, even the ability to style a dropdown, like customizing form controls, all of that came from like very clear developer evidence that these features are needed because you're not going to see it like as a user, right? But developers are asking for these things and it's something that was very useful with Sass. Um, so yeah, a lot of these features kind of need evidence. Like even if there's a hypothesis, like I think developers want this great, but I sometimes often need to prove that there's a community need, um, to prioritize it. And funny enough, CSS nesting was the reason that I finally said, okay, I don't need SCSS SaaS anymore. I can just use CSS now. And I'm way happier since, but I, I, CSS nesting was also the first and so far only CSS specification that I read because I wrote a blog post about it. And I was like, okay, this is really tough to read. And like LLM at that, it was like 2023. So I would, I was not convinced about LLMs at that point. Uh, so I read it up and down. I was like, this is kind of confusing. There's a lot of terminology in there too. That could be really confusing. Um, yeah. And, and also it's like, there are a lot of edge cases covered before it's like going to the actual like meat of it, if that makes sense. Right. Cause you have to cover all of your cases. If you're writing a specification, the browser's different. For sure. For sure. Um, okay. What is a platform draft feature that is in the works right now that you're super excited about? In the works, uh, there's, there's a lot. Um, I think for me, one that I have had a lot of investment in wanting for a while and have been a part of from the start is really like this journey for customizable select. Um, that is something that I have needed on the platform for so long, just like rebuilding the same thing over and over. Um, the core library landed, like the core customizable select features, but there's still a lot of work to do. Like select multiple, I mentioned even like combo boxes, things like that. Those are things that I am very excited to see being worked on. Um, additionally, like a lot of anchor features, for example, I mentioned like the anchored container queries, like that is something that is a missing feature for anchor positioning. People want to be able to restyle the anchor when it moves into different positions. Um, so that's still a work in progress and it's, I don't think it's spec yet, or there might be, no, it's not spec yet. Cause our engineer has been out. It's summer right now as we're recording. Um, but that's like something I'm really excited to see land. And now as I'm digging more into the interaction space, like I think a lot of these scroll APIs that Adam Argyle actually worked on a lot. Um, those are really useful and not just in like full page scroll, but like these micro interactions, like moving around a website is such a core capability. Yeah. Um, he had this cool demo also a couple of weeks ago where he heavily used that feature. And I was just, that's such a fun way to interact with the web. And it's like, yeah. Yeah. If you don't follow Adam, you definitely should. Also, Bramus and our team has been doing a lot of view transitions stuff and like a lot of interactions space stuff. So maybe in the show notes, we could link everyone. Yes. Uh, I'll probably hit you up for like all the links and stuff, but yes, I'll, I'll do my very best to put everyone and everything in the show notes. Um, okay. Another thing that I'm wondering and probably also will benefit from it myself. If what is one thing that you would like people to better understand about the web platform? Oh, interesting. Um, the cascade. Oh, I feel like that's an area that a lot of people get very caught up like specificity in the cascade and somebody who's like core, like low level, how does CSS work stuff? I think a lot of people turn to libraries like tailwind because they want to ignore the cascade. Um, so yeah, I'm sorry. No, you're good. So yes. Yeah. The cascade. Yeah. I had a conversation about that with, uh, Daniel Rowe on this podcast where I was like, well, this is a bug. And he's like, no, this is CSS cascading. And I'm like, yeah, okay, fine. It's embrace the cascade. That's the thing. Like if you're cognizant of the behavior, it allows for really powerful implementation, the way you structure CSS. If you're not cognizant, then you're just getting caught up by it. And like, yeah, yeah, I don't need to explain that to you. So, um, the one thing that I struggle with because CSS is to a level intuitive that you can like write CSS and get things going pretty quickly. So I never, and again, should probably spend the time, invest the time really learn CSS. What would you say is a good resource for someone who has been writing CSS probably for 10 years, but never spent the time to actually learn it? What would be a good resource? There's a lot of good resources out there. Um, we have a course on web.dev called learn CSS, and it covers a lot of the basics. Um, if that's too basic, there's also a lot of new articles about like new stuff on like, um, MDN is a great resource. MDN is awesome for documentation. Also some of the newer features like anchor positioning have like more article style, um, posts on there. Um, and there is an awesome writer that does a lot of CSS stuff. Um, developer.chrome.com and web.dev also have like what's new, um, kind of landing. Web.dev focuses on like baseline features. Yeah. Sorry. My dog is, uh, having a time. What dog is it? Just out of curiosity. He's a golden doodle. Okay. Yeah. It sounded like a bigger dog. Oh, he's like, not that small. He's a medium sized dog. Medium size. Yeah. Yeah. Um, I, I do have to say web.dev is a fantastic resource. I, that's probably the best way for me as like an advocate in the web space to keep up with platform features. Um, yeah. Also we do an end of year CSS wrapped where we, uh, do like an overview of all the things that landed. Um, that tends to focus on newer features, but we kind of do our mid-year like Google IO stuff and then end of year CSS wrapped. And so you can kind of get like a, every six month's, um, overview of things to look out for. And people ask me all the time, like, oh, do I need to like know all these features? And I guess my advice is you don't have to know how to use all of them in detail, but know that they exist so that you can use them when it becomes useful to you. Yeah. Knowing they exist is critical because if you don't know they exist, you can't actually benefit from the future. Right. In a way, that's what I like about going to conferences. I don't need to understand every talk or something. I probably wouldn't go to a conference if I already understand every talk, but like having it heard that you can like map it out once you're in the situation where it can be applied and then watch the talk again, if it's online, I think it's a, has worked out for me the best and in a similar way. That's one thing I'm curious, how close are you working with like the Chrome team on a day-to-day basis? Very. Okay. Because I can, yeah. Yeah. I work very closely with the Chromium engineers, the people who build platform features. Yeah. Okay. Yeah. That makes sense. It's kind of cool how it works because they are all C++ developers. Yes. Like they're building the engine. They're not really web developers who are building websites and like running into these problems themselves. So we get to be their web developer counterparts that interface with the developer community, are the V0 testers, are the ones who are like able to provide a lot of real world feedback and help prioritize some of these features and like identify the gaps and test if they actually solve problems. So it's very, we work very closely in this lot of like symbiosis. Yeah. This is also perfect because if things work out correctly, this episode goes out after one that I recorded with the creator of Ladybird, the open source browser engine. So, and he mentioned similar things. Like he's like, yeah, I'm not a JavaScript developer. I have no idea. Right. Okay. But so I was asking because I could also see you like being very distinctly more focused on like the platform features and yeah. So I was just curious how that, that is organized. But that's a cool approach. But that means you're more working with the Chromium engine forks, not with the Chrome forks particular that make like dev tools and those kinds of things. Is that? I do work with the dev tools team too. Okay. We sometimes interface with other teams, like where it comes to like, if we want to add a feature that might adjust like Chrome browser stuff, but that's rare. That's kind of coming up now that we're working on this feature called interest for, which lets you do like hover cards and show interest in links or buttons and like have things pop up, which is also something that I'm really, really excited to see in the browser. But that has a component where for mobile, it might add a context menu item. So that's up for discussion. We have had to talk to like Chrome browser folks because that would affect the browser Chrome for, for lack of a better word. But with the dev tools team, we work quite closely to make sure that dev tools supports like these CSS features. So at a minimum level, are there no bugs in dev tools for the new features we add? And then sometimes we get the opportunity to add some more advanced features for dev tools, like for different types of positioning. Like you might have noticed there's like grid and flex tooling. Yeah. A bunch of these capabilities have a little bit of an advanced tooling. So right now I'm working on anchor positioning tools for dev tools, where you could move things in different anchor positions and test those. And also a tool for like popovers to like force them open so that when you have something like this interest triggered popover, you can actually debug it because it doesn't go away every time you hover. Oh, that's cool. What do you mean with this interest link? This is the first time I hear about this. So I was like trying to get a mental model in my head, but couldn't quite get it there. Yeah, sorry. There's so much that is shipping. Like I mentioned, CSS is the most interesting place in web development right now. That's, that's another feature I should have mentioned earlier, but interest invokers essentially let you build hover triggered or tab triggered content. So like on GitHub or on blue sky or Twitter or any site really that has any kind of like preview, like Wikipedia, you often will get a popover that's anchored to either a link or a button with more information. Yeah. That capability is really hard to do right now and really hard to build accessibly. Yeah. So like we talked to different teams in big tech, for example, and they said they spent six months building that one hover triggered feature and had three different engineers working on just that for six months. Like it's just really hard to build it accessibly. And then like even after all that work, they don't know if they got the accessibility right. Everything that opens and closes dynamically is just hard for accessibility. Yes. But especially things that are triggered so ephemerally. Yeah. Oh yeah. You might have this like hover and then what do you do in different modalities? And then how does that speak into the accessibility tree? Like what different states should be provided? That's also why people use these libraries understandably to build a lot of components because all of the accessibility stuff is built in already. It's way too hard to do that. That's like one of these like blue sky goals that we have for the web platform is that you don't have to think about that. It's already built in. Like think about it, but you don't have to go and add all of your ARIA roles and all of your labels and like all that stuff should be built into the platform. Sadly, a lot of people still don't think about it at all, but that's a different conversation. That's the problem. Like, and as much advocacy that we want to do about, you know, care about accessibility, it's still way too hard to do it. Yes. Yes. I agree with that. One thing I'm wondering and going a little bit full circle back to the AI conversation we had in the beginning, do you, because we kind of see this shift happen from like, okay, instead of browsing for information, I just go to a chat application that, where I put in the same query that I would usually put into like a search engine and I get immediate result instead of me searching for it manually. Do you think user interactions like that are going to be changed by the rise of LLMs? And that's a very broad question. Like end users and how they interact? Yes. The web. With the web, for sure. I mean, we're already seeing it in search data, right? Like if you have the AI overview. Yeah. I think on websites, I don't know because I currently hate interacting with chat for a question that I have like on a commerce site and it sends me to some AI and I have to talk to this AI and then I have to figure out how to opt out of the AI and talk to a human. But now there's fewer humans because they laid them all off because they wanted to talk to the AI. I hate this trend. And so I really hope that we start to normalize a little bit and kind of go back to what's actually good. Yeah. Use AI where it makes sense. So for example, understanding a code base that you're new to. You've got a closed set of information there that you can query. That's like your own custom search. I think that's a great use case for AI. Yeah. Even with dev tools like debugging your site. Like, but I, I hate this, this rise of just everything is an AI chat. Everything is an AI. Like that is not a good feature. And I think that we're going to start to see a pendulum swing away from that soon. I, I don't think chat is necessarily a very natural interaction model for us as humans, even though like conversational it is, but so I'm, I'm very curious because I can see it swing either way where like, I can see a lot of website traffic go away because there's not, not just a need for it, for me to go directly there, but an LLM can go there for me more or less a little simplified. But on the other hand, we also often want to have that user experience. We want to, so it's kind of, I kind of feel it's like a trade off between like experience and efficiency. So I'm just very curious to see where this goes, but I totally get what you're saying. Like if, if there's like a chat, I'm curious too. Yeah. If there's a chat, I'm like immediately like, send me to a representative, send me to a representative, send me to a representative. Right. Yeah. I think it depends on what you need to do. So if you're trying to figure out like, what is the tree law in the county I live in when it pertains to X, Y, and Z, I don't want to be digging through county websites and finding the right page and reading some PDF. Like I don't, I want the LLM to give me the right answer and hopefully cite its resources, like cite the sources that I can verify. But if it's something like shopping for shoes, I'm not going to use an AI tool. I want to have a nice e-commerce shopping experience where I'm browsing. Yeah. And you know, I don't think that the web and websites are going away. Yes. I'm not going to be using an AI to look at photos of my friends on Instagram. Yeah. Yeah. I'm going to be using the web for what it's good for. And sometimes you need a UI. Yeah. Okay. Yeah. I think this is just very exciting times. I think. I don't think I've been this excited about like our industry and the what's going around for like at least the last six, seven years. I certainly think it's interesting. I think it's exciting and scary. Yes. I don't really know how I feel about it overall, but it's definitely changing how we build. And people who are trying to kind of ignore it, I don't think you're going to be able to ignore it for much longer. Yes. Yes. I agree with that too. Thank you. This was a great closing remark. So I think it's going to be hard to have like a better end statement. Thank you so much for joining me for this. I want to particular thank you for this because you're one of the few that agree to this without ever knowing me. So you just randomly showed up to a stranger on the internet. So I very much appreciate that. I thought it was fun. I know it took like a little time to actually get the schedule. It was. Yeah. No, thank you so much. I'm always happy to like chat. I feel like there's so much going on in the web space right now. And I like really care about it. I care about the future of the web. So always happy to chat, hear your thoughts too. I think you're one of those perfect guests for this format of this podcast because you're so excited about those things. So I can immediately tell like your level of enthusiasm. So it's just like perfect for like, okay, let's put more into this. Let's talk more about this. It was great. Thank you so much. Yeah, of course. Thank you again. And to y'all out there, see you soon. Bye. Bye.