Adam: What if there was dev tools for designers? What if there was a Photoshop looking toolbar that plopped on a page and just did the stuff they expected when they clicked and hit delete?
And it started out just me trying to empower all these designers. And I was like, I wanna help you.
[00:00:13] Introduction and Guest Welcome
Andrew: Hello, welcome to Dev Tools fm. This is a podcast about developer tools and the people who make 'em. I'm Andrew, and this is my cohost Justin.
Justin: Hey everyone. Uh, we're really excited to have Adam Argyle on Adam, did I say that right?
Adam: You did. You are not West Boss who continues to call me Argo, like he's a cold caller on my, uh, my landline, you know, but it's all good. Hey, you did well. You thought about the sweater. Well done.
Justin: Nice. Well, Adam, it's such a pleasure to have you on. Uh, you've done. So many things and you know, we've just seen you online forever. So your next Googler, you were on the CSS working group, which I think is really awesome. Uh, you've done just like so many cool, uh, UI things. Um, and we're really excited to talk about your work.
I'm particularly fan of VIS book and I kind of show everyone who's like de design adjacent. Like, Hey, look at this tool. It's so good. Um, so incredibly, incredibly excited to talk to you. Um, but before we dig more into your story, would you like to just tell us a little bit more about yourself?
Adam: Yeah. Um, I've been hacking since I was a tiny youth. Um, started in, uh, VRML, uh, virtual reality modeling language. How fun is that? Just to say out loud. And that was before the year 2000. They probably thought that was future language back then. You know, in 2020 we're gonna be hovering around in cars right.
In VRML all day. Right. Uh, anyway, I've worked for big companies, small companies, startups, not startups. I've been a consultant. I've been a consultant internally, like at Google, I would just go consultant. I've worked at Google. Worked at Deloitte. Uh, I've been making apps since the iPhone came out. And when the iPad came out is really when I started cutting my teeth hard into making, um, full stack web applications.
I did everything it, it took to make a beautiful application on the iPad one, and I've just been kind of keeping up with that ever since These days. It means I'm running multiple agents and prompting them to do my bidding, uh, as best as I can, and I'll reach in and tweak the code whenever they screw it up, which is, uh, usually just in the CSS they're pretty good at ripping off everybody else's backend code.
Um. There's a little dig there. Slight dig. And, uh, I, yeah, I was at Google for seven years, a member of the CS working group. I helped specs, which I think specs are actually, um, interestingly, a potential future for ai. Like, I like, uh, KIRO and where it's headed with a communal space for us to not code together anymore, but to edit specs together.
And I feel fortunate that I spent so much time, uh, editing specs that way. And these days I still, I still fight for the user. So it's, it's been 20 years. All I want is I want good user experiences. I like to play good video games, dammit. And so I want good apps too, you know, like, um, we should be spending the same amount of time to make those things awesome and enjoyable.
[00:02:56] The Philosophy of Design and Development
Adam: I have a thing that's like, I don't like MVPs, minimally viable products. I hate them. Would you like to use my minimally viable car? How about my minimally viable dinner? And you're like. That sounds terrible. I do. It's not, I'm not about, I'm not against minimal things. I like minimal things. It's that I want MDPA minimally desirable product giving me, look, I can have a minimally desirable dinner.
That sounds great. Gimme a minimally desirable car. That's great. Uh, I just don't want your MVP, so stop, stop. Sell it to me like it's something great. Um, anyway, that was a lot and a little at the same time. I hope that was good.
Andrew: Yeah, that definitely squares with the work I've seen from you on the internet. I wouldn't describe, uh, your style as minimalist at all. It feels like maximalist in a lot of different ways.
Adam: It's like a, I like sushi where it's like sushi packs. So much flavor and so much creativity in such a small vessel. Um, I try to do the same thing with the way that I build applications. I like to be a sushi chef, where it's like, Hey, that's just an accordion details element. You're like, but it's delightful.
He added little thingies. They, they did thingies and now it's cooler than the, the minimal one. And anyway, I'm glad you noticed. Thanks, Andrew.
Justin: Andrew, you wanna kick it off?
Andrew: Oh, sure. Uh, so you gave us a little taste of it there, uh, but what initially got you into web development? Like you have such a deep focus on CSS and like browser specs and browser tooling. What led you down that path?
Adam: Yeah. So, uh, it was a love of visual art, a love of games. I mean, and you know, I was like a classic eighties baby. I was building MySpace pages and customizing mine, customizing my bands. Um, but it mostly came down to like in school, when I started going to school for computer science, I was in Java classes, PhD, HP classes, SQL classes.
I was learning about all these concepts and then all of a sudden we came to Flash and I noticed I was playing like a lot of Guitar Hero at the time. And Flash gave me this opportunity to not just make something functional, but to add all sorts of pizazz. Uh, and I liked pizazz 'cause I was noticing that like when we built our Java applets that we ran on our console, all the other kids in the class were like, yay, it did the math.
Look at my console, it's the right number. And I was like, you're happy with that? No, no one wants that. I mean, people will pay for it, I guess, but like, no, no user wants that. Like, I don't want this. Do you want that? And so I would always go this extra mile to make it nice and to make it something visual.
And I realized really quickly, I was the weirdo. I was the weirdo in the room. Everyone else was like, yeah, dude, we're super happy. Uh, yours is, it's cool, or whatever. You know, you could see it on their face. Like, we just don't care. And I was like, well, apparently I care. So I switched schools. I switched from intense computer science.
Into intense design. And I went to design school and I learned all about typography. Like I would trace letters, like the whole classic typography thing. I was in there doing that, but at the same time I was taking art classes. I was at an agency building iPad apps. So that's like a lot of my weird two brains.
Everything coming together, all this is like, been almost since the beginning. I was in fireworks, the design tool or illustrator while I was also in Dreamweaver and I was also in VRML. Um, I'd just been that sort of like, I liked both. I want them to be visual and I wanted to understand how it worked.
That's the cool part to me. And it kept on going and eventually that led me to be like wanting to enable others around me. I was like, Hey, how come you're not doing this stuff? Isn't this fun? Look at me. I make a thing. And then it's artful too. And they're like, I can't do that. I was like, let me help you.
I'll make a tool.
[00:06:26] The Birth of VisBug
Adam: Um, and like talked about visbug visbug being sort of like one of the, um, well, it's. Pretty popular anyway, whatever. It, it got a lot of cool semen. It, and it helped me launch my career in a certain way at Google, which was nice. And the, the way that that formed was I was on Google Cloud, I was a UX engineer, I was building prototypes for the next version of, uh, Google Cloud.
So I was like really making these animated awesome next gen prototypes. And then I was also helping the team work on the design system of Google Cloud. And when you sit down with a designer, they don't want complex things. They sit down and they're like, Hey, the uh, spacing right there is a little off.
And you're like, it is off. Uh, let's fix it. And they're like, I can't fix it. And you're like, you can with this tool I made, to them, like they'd see me open up dev tools and it's like the Lamborghini hood pops open and you're like, Hey, don't be scared. Don't be scared. I know it's complex looking, but if you reach your hand right around that little part right there and you tweak just a little bit, you can change the color of the car and the designers look at you and they're like. I'm not reaching my hand in the engine to change the car color. And that's when I was like, I think I can make this easier for people. What if there was dev tools for designers? What if there was a Photoshop looking toolbar that plopped on a page and just did the stuff they expected when they clicked and hit delete?
And it started out just me trying to empower all these designers that had innocent, innocent requests and they wanted to hack on production, man. They wanted to work on the actual product. Can you believe it? Instead of in their dreamland on an art board, uh, they wanted to work on production. And I was like, I wanna help you.
And so visbug was, uh, dev tools, uh, inspired. Tool for designers to go poke, inspect, tweak, and screenshot how it should be, and send it over the fence. Back over the fence to be like, Hey, developers, I don't know how you're writing your CSS SAS or whatever. I don't care. Uh, but this padding is wrong. Fix it. I don't care if you use a variable, whatever.
This is the value it should be. Do what it takes in the system. Mr. Systems, man, you like the systems, I like the colors, you know, so here's the right color. You do the system. Um, anyway. And it has been really popular for a long time. No, no marketing, no. I mean, other than it like releasing under Google Labs, but completely organic growth.
It has 200,000 something monthly active users right now it's built entirely on web components. Everyone's like web components can't do anything. I'm like, tell that to the Photoshop web experience. And it's built up to say that to iTunes. Say that to visbug you know, like it's a wildly uh, capable component model.
Just people don't like it. I think that's really where we're at. They're like, I like the thing I'm good at. You are like, ah, I see what you're saying. You like JSX and stuff. Okay. Um, anyway, uh, that was a long-winded thing, but yeah, visbug was definitely born out of me, um, staying hybrid, wanting to enable people and I still, I, that's why I like to teach.
That's how I got the job as Devereux at CSS on Chrome was I was like, Hey, where's the CSS Dere? You guys got like six JavaScript ones. Um, and they were like, oh, you're right. I don't know why we don't have, Hey, you do it. And I was like, ah, I'm not smart enough for that sort of thing. I just like make design tool stuff.
And anyway, I accepted it and I give things my all and I gave it my all for six years until it ended. But, um, I have a lot of fun things to say along the way. Yep.
[00:09:38] Integrating VisBug with Dev Tools
Justin: So, while you were at Google, did you actually work on the dev tools, um, given that you'd like kind of done all this work on visbug
Adam: I did. Yeah. So I started working with the dev tools team very directly. Um, at first it was implementing things from visbug. I sat down with a, I have a, here's a story, one, a little background story. Um, when I joined the Chrome team after visbug was doing well, um, we were talking to the dev tools team about integrating visbug and just having it be a button you click and it would just launch.
And, uh, at first the guy who led it, uh, he's a, he's known to be a stickler like DevTool and Dev tools is written in vanilla JavaScript. By the way, I don't know if you know that the whole thing from the ground up ever, always has been, I think now it's in TypeScript and maybe use this lit here and there that y'all, that complex, the most complex app I think I've ever seen in my life.
Vanilla, JavaScript. I'm just gonna say that closer to the microphone so everyone can hear vanilla JavaScript can do. Really complex things, y'all. I don't know if you think it, I, I think you don't think it can. It can anyway. Uh, so it's vanilla JavaScript, but, and it was owned by like a small group of people that knew how it all worked.
Um, and they didn't like change. Uh, it's not because the code was, you know, not solid. It was more like they knew that what they were balancing and juggling was state hell, right? Like, they didn't own state, uh, all sorts of things. They just had a stack of things against them and they didn't care. These folks powered through every single problem and always had a solution.
Anyway, one day, one day sitting down with the dude and he's like, after he'd been telling me no for like weeks, he's like, dude, we can't do it. We can't just stick it in there. You stay as a Chrome extension. If it does, well, we'll do other things, whatever. And then one day I show up next to him and he's like, Hey, I did it.
Took me 30 minutes last night. I put your tool and my tool, the visbug was no longer floating, it was to the other side. So dev tools opened up on the right hand panel visbug show up in the left hand panel. And it was like a legit IDE vibe. You're like, I'm in a full on designer dev tool thing. What's going on? Hey.
And then that guy quit the next day and it just never saw the light of day. It was just, it was just toast. The whole thing's toast. Uh, another fun little story about that is, um, back in the day, do you remember fireworks, the design tool?
Andrew: Before my time.
Adam: Macro Macromedia. This is like, uh, early flash days. Um, illustrator days.
Everyone is an illustrator. Photoshop or Fireworks, they were the three main ones. And Fireworks was unique because it was, uh, vector bit, or Pixel Vector. Shit. They had a cool word for, they were hybrid. You edited path data and exported pixels optionally. So it was a hybrid. You didn't have to pick between Illustrator, Photoshop.
You could be both in one design tool. And honestly it was awesome. It had states and slices and all this crap that was really helpful for us at the time. But a fireworks file was a p g and all of a sudden it had all this rich editing capability, just like a design file.
So it wasn't a PSD, it was a png. Turns out a png can stash. Uh. An n number of values into its metadata. g can, and so you previewed, it looked like a preview on your desktop. You could see the thumbnail, but if you opened it up, it was huge. It was like 60 megabytes. And then when you open fireworks, all the layers and all the things all popped out, you could save.
Uh, early days in Chrome, someone figured out you could save an entire webpage into a png So was, uh, theorized that Visbug could then just be a png editor and the browser would unpack and pack the file for you. So imagine Dropbox is cloud syncing your production site into png As designers edit pngs and pngs back up, there's like a sync engine.
Ha, ah, I never saw the light of day, but wouldn't that have been cool for like a, somehow we had like a design file that was like bridging the gap between all of our workloads. Um, anyway, SBO was very fun at exposing the sort of deltas between like what a developer tool is and what a designer tool should be.
How do we unite these folks to work on the same product together? Um. And ultimately, like, I wanted designers who, who fight for the user. Like I said earlier, I fight for the user. I wanted user or designers there to fight for the users. 'cause developers are decent at it, but they're, let's be honest, developers tend to fight for themselves more often than they fight for the user.
Uh, it's my, my speed, my experience, dx, all I think about is DX ux. Yeah. That's part of it, right? I think I get that when I install Shad, you know, there's UX there. Uh, hey, I got a chuckle outta Andrea. That's nice. Anyway, um, that's just me ranting about visbug stuff. Um, but I'm proud of that tool. It's, it's been really great.
Andrew: I recently saw a post from you that I, uh, it may not have gotten integrated into Chrome, but didn't get integrated into another browser.
Adam: It did Orion. I was, so, someone sent me that too. Um, Orion ships with design tools and a friend of mine was like, design tools in the browser. What, how did they do this? And they go look it up. And they hit the visbugtton design tools and visbug slides out. So there's nothing in Orion about visbug it doesn't say launch visbug nothing like that.
It just says launch design tools and they slide out. Uh, and I was so happy and so proud. It's an open source project. I'm like, fork eight, run baby. You know, I don't really care. Enable those designers, make people feel powerful on that webpage. Uh, and yeah, that's really, really cool stuff that that's in there.
Yeah, I'm really happy.
Justin: I think it's funny. It, that's my coy, right? The, the search engine.
Adam: Yes.
Justin: So they're trying to be like a, a different Google. This is like, it's an, it's an interesting, interesting approach that they have. visbugt it's cool, it's cool that it got integrated. Uh, I wonder like, so what, what did you take to the dev tools for Chrome that like was inspired from like visbug 'cause I, I remember there was a time when like the dev tools weren't really that fun to work with.
There's like, you know, there's a lot of it, it's a really complex interface like you were talking about earlier, and we've gotten a lot more capabilities over time. So I'm, I'm curious if you like, contributed any, uh, of the sort of like learnings that you have from bvisbug into the depth tools itself.
Adam: Awesome. Yes, there's, so there's two pathways to talk about. One is literally things that they took from VIS BU and put into dev tools. And then the second one was like the long tail of my work was as new CSS features came out, uh, or H TM L features, both of those needed tooling or we would, we would argue they needed tooling.
We're like, you can't release the top layer of the dialogue without giving people a way to see what's in the top layer or where it even is. I'm like, if it's just a completely opaque. Space, like that's asking for trouble and we can simulate what it is or whatever it is we need to do. So, um, the first part of the work was like one of the earliest things, Fiz visbugg features that made it in code dev tools.
So when you do inspect element from dev tools and you hover over elements, you'll see a preview of the font, the, uh, font size, the colors, maybe some of the contrast and a few other things. That's a, that's one tool of visbug it's the inspect tool. And that's, that was made to give designers a quick scope. Uh, you any all gamers, shooter, gamers, quick scoping. No. Alright. Anyway, for anyone out there who doesn't know what quick scoping is, that's when someone runs around with a sniper gun and just imagine hands bopping in front of them, Bob, Bob, Bob. And then they see someone poke up on the rooftop. And for some reason, these psychos who play this game all day, they lift their scope to their eye and they shoot the person in like less than one second.
I'm talking like a hundred milliseconds. They point scope in, zoom in, shoot the person and, and, and defeat them or whatever. And then they just keep running. And I, I've not, I'm not a quick scoper, but I've always loved this concept of like macro to micro, macro to micro forest for a tree, forest for a tree.
So that particular tool is, uh, capable of showing you the styles on a tree. Um, and they, and overnight again, that same dude, uh, overnight was just like, oh, that's a great idea. All we do right now when you hover over an element is highlight the padding and the margins. Um, we totally should show this little tool tippy thing.
So all of a sudden a tool tippy thing popped in there. Um, and I had other like color tools, I had guides, um, I had measurement tools. There's like all sorts of things that, and you can see rulers in vis in dev tools if you go turn 'em on. Um, anyway, okay, so there's like certain tools and aspects that they found really compelling.
And also one, here's one really interesting thing about visbug is visbug exclusively works on collections. So a lot of times when you build an app that can select things, uh, you'll start out by managing state and say the selected item is this one, right? And you say, ah, state is equals selected as equals, this element or whatever.
visbug always assumes a collection. So there's never one selected item. There's always many. And a power of visbug over dev tools. Dev tools can only select a note at a time. I don't know if you've ever thought about that, visbugt you can only see the styles for one thing at a time, and visbug allowed you to hold shift with that inspect tool and just be like, Bing, bing, bink, bink.
Show me five different elements, styles at once and then I can compare them to see the delta. You know, maybe the colors off or something like that. So anyway, it's just kind of fun. visbug always worked on a collection and so dev tools, uh, starts borrowing all these features and then all these new H Tm l and CSS features come out and they refer to us almost like consultants, the CSS kind of Chrome Dev Rel team about like, Hey, how do we visualize this?
How do we help people feel empowered by this? 'cause we wanted to release new CSS features with an associated tool. We felt it drastically helped adoption and helped developers feel, uh, empowered by the features. So again, it was me wanting to empower those around me to get that stuff going. Um, and that turned into things like, um, I had a whole document at one time.
It's like tons of different tools and I tried to pitch dev tools, not changing their entire tool set. The first thing I did was pitch to, okay, so, uh, nod along. If you know that CSS is a fully typed language,
Justin: Fully typed.
Adam: it's a fully type and it's enforced at runtime, nod your head if you know. No, it's nodding their head. See, yes, CSS is fully te. You've tried to put a color where a pixel value should go, right? You're like font size red does the application crash. JavaScript would. JavaScript would be like, and you've assigned a value that I cannot do this operation on.
I'm gonna crash the whole time. CS doesn't care, it just steamrolls it and says, well, is there another valid one that's trying to assign me? Because they, they're gonna win wherever they are somewhere. And it's a typed language. The font size can only accept a length percentage. That's a typed variable that is typed of other subtypes, which is length and percentage, right?
So it's very much like typed script. If you wanted to, you could do the whole C system language from top to bottom is a type safe. Um, and developer IDE centric experience, that only shows you valid values that you can provide at certain times and would show you red squiggly, just no one's built it. I'm not sad.
In fact, I'm really sad. I'm really angry and no one's built that. But we're probably past that at this point with AI showing up at. So anyway, the first thing that I pitched the Chrome Up tools soon is they were called typed components. Uh, and they were for CSS types. So if you saw a CSS length unit, like a pixel value, I was like, here's all the things users should be able to do with pixels that they do in design tools.
They should be able to drag that to the right and to the left to make it go up and down. If they hold shift, it should go up by 10 and down by 10. Um, you know, like, here's the modifier keys and I built prototypes and we built that into dev tools. We also built the, um, rotation, like the, and an angle tool.
So anytime an angle is used as a value, the dev tools can assume this angle tool can empower a designer or developer to tweak the angle. Um, there was also, anyway, so this is what I meant by like type, there was a gradient type tools, like it looked at color stops and it had, anyway, it's focusing on types.
'cause then they were like small and bite-sized and they could chew off what they could as they went. Uh, but dev tools was continually, uh, their funding was cut year after year. So we saw a slowdown on. Fun features and a survival, uh, instinct kicked in as people are like, they're eliminating us every year.
What do we do? And we're like, I don't know, but I don't know if you've seen Dev tools team, but we are smoking in CSS land. We are, features are rolling out fast. And they were like, yeah, we can't keep up. And we are like, well we know, um, but we're not gonna hold it over your head. It's okay. We were really nice to them.
Um, so anything that they could produce was always good, but, uh, we were constantly consulting them on, we wanted developers to feel empowered. So yeah, I had to expose all the intricacies to people. Yeah,
Andrew: I, I love some of those tools that you guys added. I'm pretty sure the box shadow one was another one in there. 'cause
Adam: that was an early one. Yeah, it had the little air. Yeah, the dots you could pull around.
Andrew: yeah, I wa I, when I tried to ignore box shadows for a long time and just use that and just because of using that, like the transition to like actual values was a lot easier. 'cause I was like, oh, I know they're similar to the, the, the sliders.
Adam: Yeah, the easing tool is another one that had an early implementation, but later we drastically enhanced it, especially when linear came out. The linear easing function, uh, needed some changes to the, uh, easing. We had a whole typography one, um, because there is a typography one, it was built by an intern. so weird. So lots of features in dev tools, even at Google in general, were like intern work. So you'd have like interns building really cool user facing things and I'd be sitting there going, why don't you ask me? I would love to build this tool. And then I would, you know, and then I could maintain it after the internships done or whatever.
Um, but those folks leave and so we would, we'd inherit, um, a very. It was an MVP, it was a typography tool, MVP, uh, and it had weird limits, like, why is the max font size 72 pixels? Can I use rims? Can I use s? The answer was no. Like, well then this is dead to me kind of immediately, but whatever. Um, we wanted to enhance so many of these little tools that, uh, were fur those moments.
Yeah. Box shadow tool, text, shadow tool. There used to be a moment where you could hover, uh, in the styles pane and in the bottom right these little icons would pop up. They, we told no one that they were even there, and you'd have to click 'em, just experiment, be like, what's that one doing? And it would open up something like the font tool or the, uh, shadow tool.
And pretty funny had some growth issues there on DIP tools as the styles pain started to get very overloaded. Um, that element list, that styles list of all the styles being applied and all the cascade layers and all the, Ooh, it got really hairy really fast.
Andrew: Especially if you have a bunch of CSS variables at the top level. It's just like enormous list.
Adam: Enormous list. Yep. Tailwind. Yep. You're always like scrolling past all the things. You're like, I don't need any those. Okay. Yep.
Justin: What do you feel like, uh, of the current, like generation of dev tools? What is, what are the areas that still, like we don't have good enough tooling? What's lacking in our current dev
[00:24:27] Future of Design and Development Tools
Adam: Well, CSS, um, that's the easy one to say. Um, I'm still, and, and I waffle back and forth, but I, I still believe that it's a shame that many of our, um, previewing tools for like, whether it's like a design tool or something like that, there's so many, um, synthetic renderings of stuff. Um, and I wanna see more.
Design tools that can kind of live with developer tools because, uh, they're rendering reality. Like a good example is like Figma is in its own la la land. You know, like you're like, I'm writing Flexbox, and you're like, no, you're not. That's synthetic Flexbox. You're like, what do you mean? Well, you've only got like 25% of the features of Flexbox in that tool.
And they're like, oh. And then even when it does output Flexbox, it's like verbose whack Flexbox. And it's like, you don't even want the junk that comes. I mean, maybe it's changed, but, um, like I want, uh, designers to live closer to, um, the reality. I want them to work inside of the Chrome renderers. That's what, that's like another thing that visbug cad going for it.
It was like that was your real product. Any tweaks you. While they were temporary, there were tweaks in the real place that your app lives. So there's none of this dual world mentality that we had to do. So I'd love to see more unification of, um, just where we spend our time seeing and interacting with the tool and giving people more power in the space, in the where we're all supposed to be together.
Um, but maybe that end and ends up being specs. Like honestly, I think a kiro is a good example where like designers could stop worrying about design and development land or code at all and just start, um, collaborating in specs and the specs. We change the specs as a team and all of a sudden the app changes.
Um, that could be kind of fun. I.
Andrew: Yeah, there's so, so many foot guns when trying to translate a figma design to like actual code, like how they do borders. Like, I don't know why they ever put borders on top of the border. Like, why, why did they even make that an option? Uh, same thing with like filtering, uh, between layers. It's so different from going from Figma to an actual browser that it's like you just have to tell designers not to do the fun stuff sometimes.
Adam: Yeah. Yep. Color. I mean, um, color isn't really complex. We all think color color's just like a primary color. No color's. Wildly complex, even units. Here's a question. How many CSS units does CSS have now? So if this is like pixels is one the IC unit representing the water character in Japanese, I'm sure you know about the IC unit.
Yeah, no worries then. No, I'm, I was kidding. Yeah, no one knows about that one. Um, the character unit, the CH unit, um, anyway, there's how many wild guesses at how many units there are on CSS now?
Andrew: I had have to say it's like dozens. 'cause I know there's like LVH and like all the different view height ones there. It is kind of endless.
Adam: There's 54 and you're, you're right though. Yeah. Um, over half of them are the viewport units. 'cause you got vw, L-V-W-S-V, WDVW, and then you have the logical variance of all of 'em. And that accounts for over half of the total. So like, we think of 54, like that's wild, but Oh, and then you have your container units.
So you have container width, container height, container inline container block. Um, but yeah, uh, that's something too. I'd like to see, like there's a reason all those units exist. It's not like some CSS fanatics were like more units, uh, what we need, we shall create more for no one. No. It's like, no, these units have like wildly legit use cases.
And I feel like it's one of my superpowers is like knowing what units are available. Like you're not gonna ask your AI to give you a relative unit. Or an adaptive unit to the viewport or whatever, you're just gonna be like, make the font size bigger and you're gonna be like, and I'll auto accept yolo, whatever you say.
And so I'm over there like, no, I want these kind of units. You know, like I'm very specific about what I want. Um, and so I feel, I feel a little bit more equipped sometimes to tell something what to do because I have the articulation for it. But anyway, that's a little besides the point. But yeah, CSS, uh, it's, it's wild.
It's growing a lot.
Justin: It has grown a lot. Uh, the capabilities are, are kind of incredible. Uh, the container queries in in particular are like one of my favorite recent features. That's just so good.
Adam: Super good. Did you see container state queries? So there's also style queries. We've seen those.
Justin: Yeah.
Adam: those are cool. The state queries are cool where you can ask scroll state like, Hey, am I stuck or not? Me is one of me snapped. Which one is snapped? Am I snapped? Something is snapped co. I'd like to know what snapped.
Am I even overflowing is a scroll bar showing, and that's just a CSS query you can make now on the container. It's pretty neat stuff. Um, yeah.
Justin: that's one. One thing that's always been a pain for me is custom scroll bars, custom styled scroll bars. It's like something that like, I like really hate doing. Always wanna avoid, and then like there's some PM or some designer saying, but it looks so bad on Windows. And I'm like, what do I do about that?
Adam: Yeah, they've got new scroll bars now. They're called fluent. Uh, I'm a scroll. I, I don't even know if you're bringing up scroll that you know that I'm like a scroll knowledge dork, but I know a lot about scroll. That was my talk at CSS day just a few months ago, uh, was making beautiful scroll experiences.
And I do, I use the web kit, scroll bar styling, and I make one to just. Shifts. Kiss is nice, and then I'm like, and then we'll upgrade to the newer version. Um, if those aren't supported, which is basically Firefox and saying, here's the accent, or here's the color of the thumb and here's the color of the track type of deal.
And they we're trying to make them, um, as beautiful as possible, as integrated. I want the scroll post to look integrated. My, my, the problem statement was the same as your designers and your PMs. It's like they don't look integrated. The scroll bars look foreign to the system. How do we fix that? Um, and so the whole sock was oriented in how to make your scroll bars, how to have your cake and eat it too.
Uh, making beautiful scroll bars. And those are touchy though. Some users show up and they're like, why'd you touch my scroll bars? Like, now I don't know what to scroll or what to grab, blah, blah, blah, blah. They're just like, lost. Um, and then I don't know what to say to 'em other than like, apply a user style.
Like your user styles in your browser will always win. Just strip 'em out. I don't know if you see overflow, just make sure it's never there. Um, that's not really nice to say to anybody, but. Yeah, it's a, it's a hard space customizing those scroll bars, and it's not easier. In fact, anything, uh, there's a now standard way to style a scroll bar, and it's very hamstrung in its capability and it's because, um, users have an expectation of what a system scroll bar looks like.
And so I empathize where it's like, as soon as you change the scroll bar, they go, where's the scroll bar? And you're like, it's where scroll bars always are.
[00:31:09] Challenges with Custom Scrollbars
Adam: And they're like, but it doesn't look like my normal one, so it's not natural for me, and I don't immediately gravitate towards it. And you're like, well, that's a really good thing to say.
Uh, I don't know how to tell you. Yeah, it's tough.
Andrew: Yeah, that conversation's very top of mind for me. Right now. I've spent literally eight plus hours this week trying to fix a scroll bar problem and with all my might trying to avoid implementing a custom scroll bar, 'cause that just opens up whole new cans of worms that I don't even wanna talk to.
People love out.
Adam: Oh, you mean custom scroll bar? Like you have to draw the thumb and draw the track and you're like listening for Oh, yeah. Yeah. That's bad news. Um, there's so many things in there that you don't even know exist, and that's one of the first parts of my talk is I'm like, uh, people, the scroll bar over 30 years has so many features you don't even know, like if you were to go build this from scratch, the amount of keyboard hotkeys you'd have to support so that users can do, it's just crazy.
And then, and then directionality, and then international directionality. I'm like, I can stack this on you for days, and you're gonna be like, I shouldn't make my own custom one. Um, but if you've seen the new kind of specs for, um, scroll buttons and um, uh, scroll, uh, scroll markers where you can create dots from CSS. you can create the buttons and the dots all from CSS, um, that the dots articulate, scroll to areas. So you'd say, Hey, this, this element, this image in this thing, produce a dot for any, every image in the scroller, and it goes dot, dot, dot, dot, dot, dot, dot. And it's dynamic. So you add elements to it. More dots show up, you remove anyway.
And then scroll buttons too, so you don't have to wire those up yourself. They'll always scroll the scroller in the same way that the, um, well, not the same way, but you know how like some scrollers have arrows on the top and the bottom, and they nudge the scroller by like two pixels, and then I see people click that.
I'm like, I am really frustrated watching you click that button. Uh, okay, I hey, you scroll your way, whatever. You know. Um, so like, you can also create scroll buttons, which essentially do like a page up or a page down, or a page left and a page, right? So when the user clicks them, they scroll almost a hundred percent, but enough to keep a little bit of a.
Peak into where you came from so you're not disoriented. So it's just like really thoughtful stuff. Uh, the browsers do for scrolling. I agree. Andrew, you should not get in there and customize it if you can do it. But wait, I wanna hear more. Tell me what you're building.
Andrew: ~~Uh, ~~so we have a data table. It doesn't use browser scroll for some various reasons that we can't work around. So
Adam: Infinite scrolls. Yeah. Probably just a recycler view. It's got a appendant. Yeah. You're trying to show 10,000 rows. Yep.
Andrew: And so our current scroller thing leans into the browser scrollers, but tries to measure them to reserve space for them. Uh, and that works in all the cases, except when you're on Mac Os and only have a track pad. Uh, 'cause lo and behold, scroll bars have zero width and height, uh, when you have a track pad.
And,
Adam: Under an overlay mode. Yeah.
Andrew: when they, you haven't actually scrolled it. So because of that one thing, we kind of have to kind of rethink a whole lot of it. And no fund, fund to code.
Adam: I've built a lot of infinite lists that had, um, lazy rendering and conditional rendering and viewport awareness. And have you heard of, I I don't mean to like sidetrack, like I'm sure your solution is, is is awesome.
[00:34:19] CSS Properties for Virtualized Lists
Adam: Um, have you heard of, uh, content visibility and contain intrinsic size, the two CSS properties and their values?
Andrew: Uh, I've heard of them, but not how they might relate to this scroll, uh, issue I have.
Adam: Okay, let's say you're, uh, your Spotify, you got a playlist of 10,000 songs in it. There's a massive benefit. You have to, knowing that each row is the same height, and if you know the same that all your rows are the same height, you can tell the browser contain intrinsic size. Here's the height that I know.
They're always gonna be a a hundred pixels. Let's just say it's a hundred pixels. So the browser goes, all right, well now I can assume every one of these 10,000 nodes is a thousand pixels high. I can immediately draw the scroll bar size. 'cause I, I can. I don't have to render 10,000 to discover the height.
I know the height. Okay, so that's step one. Contain intrinsic size. You hint to the browser about the rendered size of this node, uh, as it enters the viewport. Second thing is content visibility auto. And this tells the browser, Hey, it's okay to, um, not render this if you think that's okay. So with those two CSS properties on your list of 10,000 items, the browser will only render the ones in view.
You can grab the thumb on the right and whip to the very bottom of the scroll bar. And get a perfectly fast render of those last a hundred thousand items or whatever. Scroll up, scroll down, and the browser basically does all the recycling and all the optimizations needed to only render what's in view.
And because you gave it that height and you told it, it's okay to toggle the visibility, it does it all. So you literally could then go, oh, is this playlist 100,000 items? Browser doesn't care. The entire thing is virtualized at that point. Um, and the browser is in control of that entire render path. And that's a fun way to quick, a quick win for a humongous scrolling area is to use container intrinsic size and content visibility.
It offloads a crap load of work to the browser, and they can do it when needed.
Andrew: Yeah, I'll definitely have to look into that. I don't, I don't think that might relate to this particular problem I'm having, but, uh, for just virtualized lists, that seems like such a great go-to.
[00:36:18] React and Infinite Lists
Andrew: Uh, react is currently working on a offscreen thing where they don't run any of their react for offscreen stuff.
So if you have a bunch of state that's in your virtualized rows, uh. It can like pause that and stop work on those and then like use it when it comes back into view. Pairing those two things seems like you have like an instant, like good virtualizer.
Adam: it's totally, you know, that's, that was like what I got into React, react for in the beginning. The first React component was literally an infinite list. That was the, that was the value prop was look at, look at how we can render 10 thou. And I was like, I was stoked because I was using a, a plugin called, I scroll four and then I re, I rebuilt my own scroll.
So yeah, that was its own it rebuilt. Scroll from scratch just to do the infinite list. This is, uh, cubic, this is so dumb. I can't remember my neighbor's names that like lived down the street or other names from kids at the parent, but I can remember stupid JavaScript libraries from 15 years ago. I hate it. Anyway, cubic, if you're out there, that's a really cool tool. Yeah. Oh yeah. It's I school for. Anyway, react came out and it was like, we're, we're just a component model, you know, like we're not a framework. We just, uh, conditionally rendered based on some rules that you give us. And I was like, that's cool.
And they had the Infinite List demo and I was like, that's a really nice infinite list. And I was just, I just finished working with, um, windows eight. Uh, had a entire H TM L framework for building apps on Windows eight. It's called win js. Um, and their list view component. It's fantastic. Still better than I've ever seen anything to the state.
It worked and was made to run on really crappy tiny CPUs. And, um, it was very, um, programmatic though, where like you did, it wasn't declarative. You would get a callback for every single item that was nearing the viewport and it would pass you the data. So you would give it this whole big data and a render function and it would do all of the skeletons for you.
So it would skeleton, pseudo render, um, infinite list, conditionally render everything. And if your element was coming into view within the right amount of time and everything, you would get your function called, your render function called with the piece of data. And you'd have to build up the dom, um, using document, create element and stuff, which I still think is.
Great. I know a bunch of people are like, ah, that's, I hate it. And I'm like, that's fine, whatever. Um, but I also used to build stuff in Flash where I was like, draw a rectangle. You know, here's the width. You know, like to me, like the dom is like, does so much sizing for me. I'm like not annoyed by it. But anyway, wing js list view, phenomenal.
And it also could do this thing called Semantic Zoom. It also had grouped list views. Everything was virtualized, everything was always blazing fast. I still haven't found one that's that good to date. Um, but maybe React will do it finally with this like in view and out of view, um, sort of conditional, you know, rendering.
Maybe it's an early exit, maybe it's a pause. I don't know. It sounds cool. It sounds cooler to say it's pausing. We paused it. The promise is just unresolved. And you're like, that's great. We love promises.
Justin: Yeah, react is doing some, some magical stuff these days. Uh, it's, it's, it'd be interesting to see what they come up with.
Adam: Yeah. Did you see JCO E four Alpha Beta or Alpha just got announced or whatever. They're like, we're still kicking.
Justin: what's, what's new in the world of jQuery.
Adam: I have no idea. Other than they're like releasing a new version. It's probably smaller than ever before. 'cause the browser does more stuff. But
Justin: that must be nice for them though, right? They're like, oh, all these like old like hacks and stuff that we did. We can just like start removing a bunch of these and hopefully still have the same compatibility or whatever.
Adam: Totally.
Justin: It's gotta feel cathartic.
[00:39:53] CSS Working Group Experience
Justin: So, uh, I wanna talk a little bit more about your time on the CSS working group.
Um, so like, what was that, what was that process like? Uh, what kind of features did you contribute to? And I don't know, what'd you learn from it?
Adam: Nice. Yeah, this was, so, I have plenty to say. The specs that I worked on, uh, that I got. Added as an editor too, was color four and color five. Um, scroll two, which was a lot of scroll snap features. So I worked a lot on the scroll end, JavaScript function, um, to, uh, programmatic access to, to managing scrolling CSS scroll features.
Uh, I did a lot in scroll. Um, what else was I a spec editor? I feel like there was one or two other things. Um, anyway, so to become a spec editor, oh, let's just chat about that. Like, what does that mean? How'd you become a spec editor? I was in the meetings. I was in the calls. Um, I was expressing, uh, concerns or validations or different co um, comments, whether it was in the call or through GitHub.
Um. About these various things. And I was, I was interested, I had needs that I wanted to see. I was also, I study so many design tools that I'm just like, here's what they're doing here. Like, um, we're gonna get that as developers, that's what they're handing us and we need ways to take it forward or whatever it was.
Um, and so you get involved in these conversations, they start to, uh, problems get I articulated or new features get articulated. And as soon as everyone agrees, they're like, yes, that new feature would be great. Um, they're like, who's gonna write it? Someone's gotta go do the hard work now. Um, and I would get either raise my hand or be suggested as someone that edits that as sort of like a knowledge expert who knew either the problem space or the solution space.
Oh, CSS nesting was another one I did, uh, nesting was because, uh, I was like, we, we need this. It's an ev it's every pre-processor does it. We would ship smaller CSS files like blah, blah, blah. There's like a hundred reasons that we needed CSS nesting. And they were like, yeah, but it's complex. It's gonna need, and so they assigned it to me and I, uh, worked on that with Tab.
So TAB knew how it worked and I knew what people were doing with nesting today. And together we built a spec that, uh, hoped to make browsers happy and users happy. Um, and in those meetings they could be. Um, kind sometimes, and they could sometimes be quite, um, rough. Um, a lot of times the rough sides were people not feeling heard.
You know, you have a, you have a group of people and someone shares a thought and then everyone continues talking about something else or whatever. And that person would be like, I, I'm not being listened to. And they'd get upset or, or literally no one would be listening to them. And it was totally valid.
And there's also some mean people, there's like people that were like, um, strong voices, so maybe they're not mean people. Everyone, there was a nice person just sometimes if you squinted, they sounded really mean or mad and you'd have to be like, I'm gonna just take this with a grain of salt. This person's just very passionate about this, uh, particular thing.
They're saying, oh, here's fine. Have you ever heard of the FG scale?
Andrew: No sir.
Adam: The FG scale is a way to articulate how much you care about something. FG stands for the F word given, uh, F's given. And so like in a scenario where like five people are talking about this thing and they're like, you could tell someone gives a lot more fgs and someone else. I always just like that when people could talk about that.
So we used to do, um, you know, planning poker. Did you ever play planning poker? to figure out how many points or t-shirt sizes things are. And so whenever we had a battle, this is at like one of the agencies guys had, whenever we had a battle about how long or how difficult something was gonna be, and we'd start to argue about it, I'd be like, you, this is way harder than you think it is.
And they'd be like, nuh, I've done it before. It's super easy. I'd be like, you're mis accounting for this. And all of a sudden they'd be like, eh, everyone hold up. How many fgs. How many fgs do you care about this particular thing? And I'd be like, four fgs. And they're like, damn. He put four fgs down, he's really okay.
Uh, Adam, you take it, you own it now you put all your fgs in there, it's just yours. You think it's hard, you're gonna, let's show us. You know, like you own it now. And I always liked the FG scale. It was like this like weirdly blunt way of quickly articulating, um, how much passion you had for something or whatever.
Anyway, so the community group would have these moments where there's kind of butting heads, um, and they'd have to generally cut, cut the call at that time, or cut that conversation off and go, okay, uh, it's clear. There's no resolution. It's gonna happen today. We're gonna go kick comments until next week or maybe two weeks meeting down the line.
And so, um, it was illuminating though to see the amount of, um, people participating. So in a design system for example, you might have, um, some owners, but usually there's like a group that kind of owns the whole thing. Imagine instead no one owned the design system, but um. You had anyone who used it in any form.
You had a invited expert from each of those groups. Um, and they were the ones working on the design system. And then the people who are building the design system have to listen to whatever that community group is doing. And that's basically how the browsers work. The people who build the browser don't get, just go put willy-nilly stuff into the browser.
They have to do the things coming through that's approved in communal space. Um, and it was kind of cool. But yeah, you'd have a, you know, a design team that's like being, has input from the product product managers and then input from the backend team and input from a database team. You're like, why is it because they, they render rows and and tables and they're interested in the table component.
And so even the CSS working group, you'd have people very hyperfocused on one specific thing. Um, and it was awesome because it'd be like, alright, so hey, we need CSS masonry, for example. Big, uh, topic right now. Lots of conversation route. There's only a few layout specialists. And it's important to have them on the team because while we all can talk about what we want, uh, they'll, they're much closer to the implementation details and how it can actually get built, um, or how it will be specked.
And then you have the browser people coming in. It's like, well, I'm gonna write the code that actually puts the boxes in the right spots. So, uh, you need their input as well. And so it's just really nice you get this healthy amount of input from anyone who's a specialist in a particular field. Color was another one.
Um, print was one. So you'd have someone there who's always there thinking about print. Oh yeah, we have display masonry. Okay. What happens when I hit Command P And, and literally like what happens if you hit Command P right now and it's something has display grid, not even masonry, just display grid over half the time.
It's a shitty, it's a shitty print. It's not gonna look like your CSS grid. It's because, uh, as a tons more work and the browser teams don't hire enough people to work on 'em. And so they're like, uh, they have to cut corners somewhere and print often gets, but then you have a CSS specialist. But the thing is, the spec is ready.
Because the person who's in the, uh, CSS working group is there owning it and making sure it's all good. And so, um, I felt my role in CS working group was, 'cause I'm a builder and I've been building apps for 25 years. Most of the people on the CSS working group don't build apps. Um, they don't even really build websites anymore.
And the people that build browser engines don't build websites or apps. I think that's so weird. Um, small tangent side note that I found one type of engineer, um, at least that I've seen in this world, can build the thing and, and make stuff with it too. And that's luthie Air. The people who make musical instruments, if they make a stringed instrument like a mandolin or if they make banjos or they make guitars, almost always you find a luthier who builds beautifully engineered instruments can play them too. For some reason, browser engineers, they don't know how to make websites. They, if they make a, if they make a demo, you're like, my goodness, this is not just ugly. It's, you're barely hanging in there, aren't you? Um, but you're the one writing all the code behind what I write. That's so strange to me. I'm like, uh, you don't know anything about the space, about what goes on after you write the code and browser.
Okay. It's cool. Um, so anyway, that was a lot of ranting about the CSS working group. I hope I answered something or.
Justin: That's super fascinating. It, it, it always, it always, it always surprises me that the web is as successful as it is and it works as well as it does. And that it feels like it keeps getting better because it seems like it would be a giant house of cards, but like, people do good work. Um, you know, they do say don't design by committee, but like sometimes.
Adam: Yeah, I think that's what's keeping it alive. Um, it does move slower, but uh, when it moves, it moves in good, healthy directions. And then the fact that they can't deprecate anything that comes back to that seems like the worst decision. And then it's consistently like the best one. Um, anytime I open up Xcode or Android studio, I'm like, oh yeah, not deprecating things is great because my build doesn't work anymore In this new version of the IDE that doesn't give a crap about the IDE version that I used when I made the, oh my goodness, they're all just moving forward so fast and just canceling anything that was old.
I'm like, oh, it's so nice. The web doesn't do that.
Andrew: That must make the working groups kind of feel very high stakes at times. 'cause it's like the, what we commit to now is what we're going with. It's what we're locked into and what we have to support. Like, I know there's been a lot of arguments around like, just where to define the masonry, uh, attributes.
Like should they be grid attributes? It's kind of a grid. Uh, who, who, who's to say.
Adam: Yep. And that's what leads to a lot of the heated moments where people are like, um, we're gonna have to live with these decisions forever. And so you don't wanna let those decisions get made by just a couple of individuals. They need to get cross-referenced and cross-checked and tested and prototyped and validated before they make it in.
There have been accidents. I watched a couple of them and it's not like we were moving too fast, I guess we were moving fast enough to make decisions, but it was more like, okay, so a good example is Anchor CSS anchoring. Which, uh, only had a couple name changes to the properties and some values were added.
That made things easier. But that was a review that came later after Chrome had prototyped. And that, you know, the thing would be Chrome would spec it a year ago. Um, continue bringing up spec issues week after week. Just refining it. Refining it, and it would be this like slow burn. And so all these people in the meetings are like, anchor's not ready.
Anchor's not ready. And all of a sudden Chrome would be like, we prototyped the whole thing. And then everyone would be like, oh shit. Time to go look at what it does. 'cause we're all news about it. And then like three months later, Chrome would be like, it's solid. We're gonna ship it. And then even more fire would get lit under all these butts and all these people would be like, uh, and so they'd show up like at the last minute, after all this time and they, they'd be like, you can't, you can't do that thing.
And we'd be like. Where were you for the past 15 months? You know, like you can't just show up and, and throw a wrench in a bunch of spokes, but often they did. Oftentimes they did. And sometimes it was very good. Sometimes they would show up and they'd be like, Hey, this, like, a good example is centering something over the anchor that you wanna be on.
So let's say you're a tool tip and you wanna be centered on the top over the, it's just a classic tool tip position used to be a pro programmatic task. You would calc your own width, minus 50% of whatever you'd have to do the math to center the thing relative to the width of the tool. Tips render itself.
It was, it wasn't, it didn't feel tedious at the time, but in retrospect it's quite tedious to, and now there's just a keyword. The keyword just does the math for you. That happened because WebKit uh, people from Apple showed up right there at the end of when we shipped it and they said, uh, this could be simplified.
And we said, that's awesome. Yes it can. These are great suggestions. And we had to undo, so there's like a chrome version, like three chrome versions with a old name of a property. Um. And so, yeah, we, we did not wanna do that. People don't want to deprecate things. It's a huge, nasty process to deprecate things and there's even a lot of safeties put into the browser to make it so it's easy to pull something if it doesn't go good.
Um, which is, yeah, there's so much code inside the chromium code base. That code base is football, fields of football, fields of code. It's wild.
Andrew: you've worked on a bunch of these features, uh, you've talked about scroll snapping and stuff like that. It's just kind of amazing how much code that kind of gets rid of and moves. Like, I go to your, I go to your, your demos and it just, like, I click on the HTML, I'm like, okay, that's, that's reasonable. I go to JavaScript first just to check, and it's like, oh, there's maybe like 20 lines.
Then CSS is like 500 lines of scroll snapping specific code. Uh, so I love all the features that have been coming out, but like in your, in your opinion, what are like some of the highest impact CSS features that have landed recently, uh, and maybe preview us some that you see on the horizon coming out that you think are gonna be really useful.
Adam: Awesome. Yeah, so like a, a good example, like I recently talked about scroll at CSS day, and one of the, to me, I, I recreated a crowning jewel scroll experience that hopefully you've experienced before, which is the Nintendo Switch scroll experience. Uh, it loads in your games wisp and have this like stagger effect as you scroll.
They, when they pop, they do a sound or whatever. It's like you've got this like audio experience. It's like, and that audio experience is as the element scrolls past the snap area, it audibly indicates that if you let go, this item will snap to that state. Then after it actually you let go and it rests at the location, a different sound is made.
Um, there's a, a, as the element is scrolling into that space, the title of the game folds up over top so that the one that snapped has, and then the, uh, the cursor, you can move the cur. There's all the, all these little micro interactions happening on the Nintendo Switch. Scroll experience is what makes you as a user go.
This is simple and beautiful, but the reality is, is you break it down hundreds of lines of code describing all those tiny, tiny little moments that give a user the sense of power and feedback. I recreated that in CSS and it used all sorts of cool new features, uh, including CSS anchoring, uh, which anchoring is a, is a huge, huge feature.
Um, packed with secrets. Uh, same with scroll driven animations. So the ability just in CSS to know something's in view or not. So you tell me React is coming up with this right now. I'm like, CSS can already do it, and if the note is hidden from CSS display, none, I don't know even know what React does at that point, but I think it's just already ran its course.
So it's like react ran its course rendered the note css, like, nope, uh, you're not in view, so you're not rendered scroll driven animation can know the width of anything at any time without JavaScript. It's almost like an intersection observer just given to you via CSS. And then with the opportunity for hooks to animate it in and outta the view as it's, uh, coming in. You've got, has, so has is in there. You've got scroll state queries to know if you're snapped, um, is it stuck. Um, things that used to take a junky amount of JavaScript to, to determine and would often be kind of janky in the way that they worked. Um, and so yeah, that particular demo, and I've commented it really heavily, you can find it on my blog, um, just goes through this wildly cool list of all these things came together in this one moment to create this really nice experience.
And yeah, there's about 20 lines of JavaScript in there. Mostly just to prompt, uh, audio sounds, you know, and to handle like a couple of edge cases. Um, like if you click a title, if you click an item, it should scroll it into the snap area. Um, stuff like that. Um, so yeah, there's tons of stuff there. Um, you know, has is still I think more powerful than people treat it.
They still think of it like a parent selector. It's a, it's a universal selector that thing can, any state that's on the page anywhere can be used by, has to tweak something else somewhere else. It's wild. So you got this declarative, reactive, um, selector. Uh, that's really, really cool stuff. Custom properties, people still barely use 'em.
How they're powerful. So like, uh, open props was a project I made. The goal was just to collect all the amazing props people put into a variable, make it easy to go use them. 'cause the CSS variable is, oh, here's fun. Okay? CSS variables are not typed. They're like JavaScript var. You can put whatever you want on var.
You can also reassign VAR to some other type. You are a pixel, now you are a color, now you are a string, now you're a number or whatever. So like both these were very, um, loose in the way that they were defined. And with app property in CSS, you can type safe a variable. So if someone tries to assign a value to it that is outside of its approved typed list, it just doesn't assign at all.
Always has a valid value. It's a guaranteed valid value that cannot be broken. JavaScript doesn't even have that. We get, we get type security at assignment time, but if, if something wrong happens, it breaks, it doesn't revert to the last known good value. Wouldn't that be amazing? Uh, maybe not. Anyway. Does, and so you have these opportunities with CS variables to both be typed and un typed and the un typed ones, these loose ones.
So it's pretty much all the open props. They can have anything in them, they want anything, and people put wild stuff in them and that makes 'em wildly useful. 'cause you can have an entire shorthand declaration in one variable. It's like you want a badass gradient, it's gradient one. You don't even know what's in it.
It could be five layered background images. Uh, and you don't have to care. Um, so yeah, custom properties are still kind of underused. Oh geez. There's some, a view transitions. People are still not using those as good as they are. Um, also those have a couple limits that are kind of weird, especially if you're in a framework.
If you're in React specifically or, or any framework where you don't control the render function. Few transitions are not that great for you. Um, but they're still cool and you still go learn what they are. 'cause like that's a fast path. Like, I was doing interviews for new jobs recently and they're like, um, okay, so make, make this render in there, whatever.
And I'm like, cool, I'm gonna animate it now. And they're like, you don't have time for animation. I'm like. Watch, and I'm like, all I do is wrap the render function with, uh, document start view transition. And now I have pseudo elements for before and after, and I can animate them however I want. Uh, it's like the, the first line of code in my JavaScript makes them all fade in as they transition in the dom.
And then the next one just says, do it something cool, you know, and I've got pre-made key frames in open prophecy. You just assign a key frame to the element coming in and boom. Now anyway, uh, it's really, really cool stuff there for dominant manipulation. Uh, so we've got scroll driven animations, view transitions, uh, has anchoring.
Uh, all the color stuff is great. All the gradient features are making more vibrant, beautiful gradients than ever before. Um, all the new units, I don't know, I could just keep going. Pretty much everything that's been added is very meaningfully being added, um, and has a use case in my tool belt at least.
Um, but yeah, check out my blog, nerdy.dev. I'm, I'm gonna keep firing off all the cool stuff. You can follow me there. I got RSS or whatever.
Justin: That's awesome. As we, as we wrap up, we always like to ask a future facing question, and I think the question I ask you is, is pretty obvious, what do you think the future of, of CSS and, and the web in general, what does that look like and what are you most excited about?
[00:58:40] Future of CSS and Web Development
Adam: I have spent a lot of time thinking about this. I've even thought about, uh, rewriting the, the way you write it. Like how could I make it better? Like, CSS is funny, right? We've seen coffee script and we've seen, we've seen Kotlin and we've seen Swift, we've seen all these super sets of powerful languages, and CSS has some pre-process, but nothing has radically changed it and everything still outputs.
CSS and then CSS is so simple and powerful that it can like be in an Arduino and it can be in, it's like, so it's like what is the next generation of that? Um. I just kept thinking of, uh, there's a Cs s article about their mistakes. So just like Node has the 10 mistakes we made. CSS has one too. It was before Node didn't.
CSS did it first. CSS was first typed. Anyway, I'm gonna stop that little gong, but okay, so those regrets in there are, some of 'em are like really obvious. It's like, why don't we make a new language that just doesn't have, there's regrets in it. Kinda like Dino did, Dino's like, well, I wrote the regrets. I'll just go ahead and make a new version that, uh, doesn't do the things I regretted.
Uh, and I liked Dino too, and for those reasons, like Dino. But the thing is, it's like, as I tried to think about some sort of superset, it still ended up being property value pairs. You know, like, here's the thing that I want to change to this. Uh, here is, and there's still like some sort of selector mechanism.
I'm of this. I don't, I, this is gonna be like a wild sort of a, uh, assumption here, but like, as I'm working with specs, I could imagine a space where we aren't writing CSS as much anymore. CSS is being written for us, just like our JavaScripts being written for us. And our components are being written for us and our pages and our right.
We're one shotting entire applications that we start to, um, get more subjective in the way that we describe it. Much like art is described, you see a little description next to a piece of art, and it's got all these words, like I could see designers being really micromanaging about the words that they're using in the spec, and then this future where, uh, you know, a committee makes a couple changes to the spec and they don't even know what the app's gonna look like at the other end.
So imagine staging isn't a predictable thing. Imagine staging could wildly change a couple of views, the whole layout and arrangement and the colors used on it, and the way that the light and dark modes interact just because you changed a few spec things. And then you would go there and validate whether or not you liked the output or not.
And then pro, you know, promote that to production. So instead of micromanaging your functions and your styles, you start micromanaging the value, um, that you want out of the application. The important user journeys, the, um, the tenets of the application. And then of course, a huge file documented about the style that you're going for.
Uh, and then it's LLMs, you know, whether it's this year or in a couple years, get so good at taking all that context that they very effectively produce a desirable output at the other end. That we aren't writing CSS anymore. As much as I don't like to think about that, it still seems like a reality. And I kind of would like that because I want other people to participate in this process.
I want other people to feel like they can make apps. It's been kind of in our hands for too long. Um, and CSS will still get powerful. And then it was just being, so users will get these features just 'cause they asked for a scroll, snap, carousel, whatever, right? And the browser's like, well, cool, I don't need JavaScript for that anymore.
Or not the browser, the LLM will say, I don't need JavaScript for that anymore. I use all these CSS features and poof, uh, we get this like handshake scenario. So I don't know. I still think at the end of the day, nothing in 30 years has drastically changed or has taken hold, like CSS has. We've seen CSS and js, we've seen it written as JavaScript objects.
We've seen people writing them in string literals. We've seen adopted style sheets. We've seen so many different ways to Benihana CSS, but at the end of the day, we still put it back together, uh, in the shape of a CSS file. Um, and I've tried some wild, oh, do you remember, um, Palm Os the. P is like an operating system.
Back in the day, they didn't have CSS, they had all the objects and all the components were just JavaScript objects nested. So imagine like one big JavaScript object and a nested element would be like an element. It's almost like you're managing the tree in JavaScript and all your styles went in there too.
It was single file. Um, it got unwieldy so fast, and then you had to learn all these magical new terms that were like, oh, it's not font size, it's text size. You're like, oh God, okay. This is a, and it just kind of like didn't land. Um, and I'm just, I don't, I don't know. I've never seen anything take it over or not.
I'm not sure if we will. I think a ai, I'll just take it over. I don't know.
Justin: It reminds me of XT js, which I had the pleasure and misfortune of using when what feels like a different life.
Adam: That was a J. Crew mobile competitor.
Justin: Yeah, they, they were really trying to, like you do everything including styles in JS as well. So it was like this kind of like object structure that like at runtime sort of build on a bunch of stuff on the back end. But, uh. It's, it's, it's hard to beat the classics. Um, and I think also it's like the cultural weight of CSS, you know, it's just been a while, been around for a while, really shaped how we think about, uh, doing style.
So,
Andrew: I don't, I don't think modern apps would exist on the web today if like they had an added CSS, like, I can't imagine any of them thought that, that, just adding a way to style the page a little bit back then would make it go from documents to like full fledged apps and like just a matter of like a decade and a half.
Adam: Yeah, they definitely didn't know. Oh, it's fun. Like tradi. Just go look at all the competing proposals too. Like JSS was one. JavaScript style sheets. That's like the nineties. Um, so it's kind of funny to see that CSS one, they, they went through a lot of the iterations that JavaScript felt like it was doing, Hey, look at this.
We could write styles this way. And you're like, they tried that actually in the nineties and we all decided this was better. But like, hey, you can still, uh, you know, build time it and that's great. Yeah, you do. You. Um, but yeah,
[01:04:46] Conclusion and Final Thoughts
Andrew: Okay. That wraps it up for our questions today. Adam, thanks for coming on. This was a super fun conversation about all the work we've been involved in and I just wanna say thank you for working on those specs. Uh, those features are awesome and just make the web better. So thanks for coming on and talking about 'em.
Adam: of course y'all are cool. Keep doing this show. I'm gonna still listen even after I've been on it.
Justin: Thanks Adam. I don't think I've learned so much in a single episode, so like hats off to you there. Always got the educator hat on so we, we really appreciate you coming on.
Adam: Of course.