The future of responsive design with Una Kravets and Adam Argyle 
===

[00:00:00] Hi, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams to improve user experience with session replay, error tracking, and product analytics. Try it free at logrocket. com. Hey everyone! So I'm Paige Niedringhaus, and today we have Una Kravitz and Adam Argyle here to talk about their recent FigmaConf talk, The Future of Responsive Design.

Una is the team lead and the manager for the CSS, UI, and DevTools Developer Relations team at Google, And Adam is the Chrome CSS Developer Advocate at Google. Welcome to the show, Una, and welcome back, Adam.

Ooh, thank you for having

What's up?

We are very excited to have both of you on today. And before we get into our talk, can you each briefly tell us who you are, and why you're famous, and what you're currently working on?

I don't know about Famo. us, but yeah I guess our team gets to [00:01:00] work on the web platform, which is pretty cool. We get to work on the things that developers can use to build websites, and what we specifically focus on right now Our UI and dev tools. So everything that's visual in the browser before this role, I was working a lot in the design systems space.

I was working as the director of product design at Bustle Digital Group right before this. Prior to that, I was building design systems for DigitalOcean at IBM, where we started one of the early design systems called Carbon back then. And I started a bunch of community meetups too. So I've always been involved in community, UI space, front end, front of the front end space.

And now here I am getting to actually work on the front end, which is so cool.

Adam. How about you tell everybody about yourself?

Sure. My name is Adam Argyle. I've been building websites for 20 something years. I'm a big fan of the web. I love its chaos. I love its weirdness. I like that. It's not some [00:02:00] sterile. Stable thing that it has all the same components everywhere. I love that. It's just funky Every website is a new possibility like going into a new town.

You're like, what does this town have for me? It's going to be weird and i'm going to be excited about it i've worked at all sorts of places small and large, been the Design lead. I've been the development lead. I've built apps for every single screen. I just love though, the part that you make it animated, you make it tangible, you make it beautiful and all those things coming together the engineering and the design is just where I love to sit and love to implement just a tinkerer at heart and just love to build stuff.

That's excellent. So let's talk a little bit about your conference talk, the future of responsive design. And I will put in a plug for it because I went and watched it yesterday before this interview. And if anybody has not seen it, Go watch it. It's awesome. The demos are great. The interactions are so cool, and you two do an excellent job of [00:03:00] getting everybody excited about CSS.

So, Go and watch it. Um,

You can't see us, but we're smiling. It's so good to hear that.

So you start off the talk by saying that people should throw out all of their current assumptions about responsive design. What kind of misconceptions have you encountered that you would say are no longer things that people need to be concerned with?

I think it's the framing of no longer need to be concerned with this kind of funny. Cause I think that we have more things that we can be concerned with than ever. But. I feel like when people talk about responsive design, at least right now, it's usually how do we adapt this to different screen sizes?

How do we adapt this from desktop to mobile? That's really one of the first huge switches in responsive design. We're at a place in time now where we're at this second evolution of responsive design where We have these new APIs, these new tools, these new capabilities, where it's no longer just about screen size.

We can actually get information about the viewport, [00:04:00] the information about device capabilities, and use those and progressively enhance user experiences that way. We can be responsive to the user's own preferences. That's a whole nother vector of being responsive. And we can be responsive to the logical components that live inside of the component the interface itself.

So we have all of these new vectors. And the idea of the talk was to stop thinking about responsive design as being limited to screen sizes and to really start thinking about these new axes for responsive design.

Yeah, getting out of the page. So it's still okay to work as pages but to think about more in your component, like the way that your artboard is inside of Figma, that's actually how we can build now that component can know if it's artboard is. Medium, large, or small, and you can adapt to it.

You can adapt to other external things. Just like in Figma, you've got these different modes and these variables that are changing colors and changing spacings inside of your artboard. We have the same things too. So [00:05:00] it's allowing you to like really focus in on that. That smaller focus point, instead of thinking about the page, we're thinking about the component and just what does it need, and where is it trying to be squeezed into?

Is it being squeezed into somewhere or is it some new relaxed space? And these concepts of compact and non compact don't have anything to do with the viewport. It has to do with this component in its moment, in this time with this user on their device. And it's all of these things rolled into this new responsive experience that we can build.

Okay, so it's less about what can we stop worrying about and more of how we can start to use some of the new features and roll them all together into a better UX experience.

Yes, that's definitely a part of it. Also, like Adam mentioned, now we can think component first. So when we had this first evolution of responsive design with different screen sizes, the change there was people started thinking mobile first. They started thinking, how do I start with the [00:06:00] baseline of this experience and expand?

Now people can think component first. So instead of the mobile layout and all the components on that page, we can take a look at every individual piece of that page. And that solves the question of how do I go from point A to point B when you're designing with the component in mind. So wherever you put that component on your page, it's a new paradigm.

It's a new way of thinking about response design, which is why we called it the future responsive design, the new responsive. This second generation of responsive design thinking is now upon us.

It's so cool to me how much CSS is able to do now without JavaScript being the brains behind it. So we've talked a little bit about components being a lot more aware of their surroundings and where they exist within a page. What other things about CSS has really come into its own in recent times and become more powerful?

And the ability for a component to know what it's trying to represent. [00:07:00] So it's that's always been the job as a designer has been like, okay, this card uh, needs to have the state of no image. So we're trying to feature an idea and not a product. Okay. So we'll design it this way. Okay. But this one needs to represent a product.

And so it's going to have a big image and maybe a little icon with a price tag and some other stuff. And we would bake these things into our art boards and we'd think about them as different moments, but they'd. In our minds be the same component. It's like one card component representing multiple different contexts and scenarios and children type.

And now that's what we have with, there's a CSS selector called has, and it's like a card saying, do I have and it can ask itself questions and then it can change itself. So its own card appearance border colors, layouts, all this stuff. But it can also say, do I have an image? And if I do have an image.

I'm going to go make the caption of that image have some special styling because there might be font colors and font sizes that are for the card, but you want the [00:08:00] caption to be a little bit unique. And so you're only making that caption have that style given a little condition that it needs to meet so it can know about things inside of it as well as the space outside of it.

And we have all these new responsive design capabilities, but there's also a lot of new CSS that is the in between. Layout algorithms are getting better. Another one is interactions. What happens in between views with view transitions or what happens in between components? And how does the user navigate the digital space of your page?

We have new CSS that can take advantage of device capabilities like advanced color spaces, which Adam can... Talk all day about I love I love chatting about my color. So there really are a lot of these new features. And the way that we're trying to frame it to make it make sense as a package is these new responsive design vectors, where that's why we like to talk about the device capabilities, new CSS that can take advantage of those, [00:09:00] the user and user preference capabilities and taking advantage of huh.

Even operating system preferences, like what the user put in there And then as Adam did a great job describing, some of these interface capabilities This core logic that the component now knows The component didn't know that before in CSS You would have to do a lot of Observing in JavaScript, and you could do scroll observers, element observers, and different types of observers.

And it was janky, the developer experience wasn't great, and it also wasn't that performant to do all of that. Now we have these things coming default from the browser in a more ergonomic way that just make more sense in how we build component based responsive interfaces today with component based systems 

Yeah, it just it follows, we're all building or not all, but a lot of us are building with react components and we think in components, so our components should be smarter and about where they are, but let's talk a little bit about the device responsiveness that you briefly touched on and you talked [00:10:00] about color.

So color is one of the things that I want to talk about because HDR color is. What is new and what is hot? And I'd love if you could talk a little bit more about what that means for us as developers and as users as well. What they'll experience when they see it versus SDR.

Nice. A good example, it's like why Apple was one of the first companies to jump on display P3, which is an HDR color space. And it makes sense because their tablets have phenomenal screens on them. They had retina, right? And in order to showcase retina so that when you held an iPad next to some other screen, it looked as juicy and delightful and vibrant as possible.

They needed to early adopt HDR colors, and that was an early distinguishing factor for them. And their tablets still look absolutely gorgeous. The color quality and everything on them is amazing. And this is a tough thing though for everyone else to catch up with. It was I'm going to do air quotes easy because it was...

Definitely not easy, but they control the [00:11:00] hardware and they control the software and they control the browser so they could go end to end and deliver this color experience faster than other people. And so the web needed to catch up design tools are going to need to catch up because they're also still behind.

But now we're at the spot where hardware has it. Almost every TV that comes out, almost every phone that comes out, they're all HDR color ready and they go. It just depends on how far they go into this amount of HDR. Cause there's like ultra HDR and so we have those ranges, but where the hardware's there, the browsers have now caught up so they can represent these colors and CSS has caught up and can articulate these colors.

And that's one of the first places to get started is just knowing that when you have a hex color, it's in a limited. space of possibility it is millions of colors, but it turns out there's still a lack of a lot of really rich light colors, a lot of really rich, dark colors. There's well, and then we can get into gradients and stuff like that.

But naturally, as [00:12:00] soon as we use a hex color, we're in that limited space. And so we're going to have to all branch out together into a new color space and learn a new syntax so that our colors can. Both be more vibrant but also be more capable in terms of what that color space has to offer. Each color space has like a superpower and that's just like a thing we're going to have to learn over time is we're going to have a utility built of colors and be like, Oh, I know what that task is.

I need whips out. Okay. LCH, Oh, I need a gradient whips out. Okay. Lab. This is just where we're at. We're at a huge shift in terms of how we need to write and talk about colors. And then as users, we're just going to be consuming these things. Just like when a HD DVD came out, I like to think about it like that too.

It's like we had VHS and we were like, I don't need DVD. It's not that much better. And then you went to someone's house and they put the Blu ray in and you're like, I think I need a Blu ray DVD player. This is pretty sweet. And that's how HDR color is. It's. Really reaching into those darker, you even have more possibilities.

It [00:13:00] was like shadows. There's less banding. The list goes on. So it turns out we didn't need more than a million colors. We needed billions. And we have them and we're in a happy place now. I think

The other ironic thing about colors is the web was just behind. You could put images on the web that showed these advanced colors and you could see those, but you couldn't get a background color to match the image. So this I've run into in my last job before Google, where the design team did a beautiful job creating the seamless image in Photoshop with all these things.

And they wanted the. background to just match the edge of their JPEG and that color did not exist in CSS. You couldn't get a background color to match it. And that's what's now fixed and resolved with these HD color spaces. We now have billions as Adam mentioned of options to reach for to stop running into that issue.

So for me, it was just inevitable. The web eventually had to catch up and finally we're there across all browsers. You can now use these advanced color [00:14:00] spaces.

That's fantastic. 

Well, modern browsers, I will say.

Adam, you touched briefly on OKLCH and OKLAB for people who are not very familiar, myself included. What are those and like, how do you know which one to use or if you're using either, what are they good for?

awesome. It's a very modestly named color space. It's so funny. I'm okay. I'm just an okay. Color space. It really should be called super ultra rad LCH. Cause that's

Overly cool LCH with a K.

Got to give it a cooler, cooler name. These are actually very powerful color spaces. Both of them. Okay. Lab and okay.

LCH can represent any color that the eye can see, which is far more than most displays can do, which is also one of its kind of. Things to be careful of is you can specify colors that might not work anywhere for five years until all the displays catch up. But anyway, so they're very capable of reaching [00:15:00] into these high dynamic ranges.

And then they also have something very special. It's their lightness channel is not just a normal lightness channel, like HSL has a lightness channel but these have a lightness channel based on the CyLab CIE, which was some studies that were done in the 60s and 70s where they took actual humans and they had all of these different shades of gray and all these different shades of purple and all these colors and they put them in front of them.

And they looked to see and they measured what human eyes were interpreting as these shifts in darkness and lightness and stuff like that. And they ended up creating an L space for lightness. That's very funky looking because it's not very mathematical, but it is very much how the human eye works.

And this is really cool for us as designers and developers, because when we say I want 5% lighter hover color. can reliably know that an okay lab and an okay LCH, if you change the lightness channel 5%, [00:16:00] every human on earth will acknowledge that as a 5% shift. It's not a mathematical shift in the color space.

This is a shift. Per how humans perceive lightness. So this also goes further into like their good use cases. Okay. LCH is the color space I would recommend you almost exclusively use. It feels like HSL. The letters are just backwards. Cause it's LCH instead of HSL.

That's so close. You're like, you should have just kept them the same. But I don't know, you got all these other backwards compatibility things to think about, but. And then if you want to use gradients, or if you're doing color mixing, OKLab is the superior space for that. And the reason is each of these, while they have the same lightness channel, they have unique tweaks for use cases after that.

So LAB being this lightness and then A and B, which are annoyingly nothing to the human turns out though that the way that those colors are packed in that space are [00:17:00] phenomenally good for gradients. And mixing colors because they pack the bright colors together and they just do this interesting packery so that you get what you expect in terms of mixing and gradients and OKLCH, which also can do nice gradients, but they're not quite as consistent and reliable as OKLab.

OKLCH though is your space for creating design systems. Like I said, when you shift 5% lightness, you get 5% perceptual change for a human. You can get into building color systems for like a map. Uh, Your map needs to have different hues and different shades. You can do that reliably in OKLCH because again, that lightness channel has another superpower.

As you change hue the lightness stays the same, which isn't the same in some other spaces, where it'll say the lightness channel stayed the same. Like an HSL, but visually to the human, you're like, that just got a lot brighter. But in terms of that color space, it stayed the same and okay. LCH, it will stay darker.

So as you shift to a different hue, you won't [00:18:00] see it go lighter or darker or kind of start to vary around. It'll stay stationary. Which allows it to be a very cool space for dynamic colors. So if you want to build colors based off an image, if you want to base colors off a user preference you can let people pick stuff and then you can go Systematically build out an entire palette build out a whole design system, a whole color system in OKLCH with accessibility in mind.

Because that lightness channel is consistent again. Anyway, so TLDR is OKLCH for your design systems and your color palettes. OKLAB for your mixing and your gradients, and you'll be set up for the future. This is a, I'd say that this particular setup of color choice for color spaces. Is five, 10 years, maybe 15 years safe.

Which is cool to think about.

That's very cool. I'm always for things that are going to last for years to come. All right. So we've talked a little bit about the color. We've talked about how device responsiveness is becoming a thing, but [00:19:00] you talked about something really interesting there, which was the user preferences. And I know.

Prefers reduced motion is a very popular one or user system preferences for dark mode and light mode on websites. Those are becoming pretty commonplace. But what are some of the other improvements in responsiveness that are coming for accessibility to make it easier for everybody on the web?

As Adam mentioned, so we have a bunch of these options now for color schemes which honestly was pretty cool to see at Figma Config, like at that event, because they now have these different modes. So you could have your light and dark. user preference. But you can go beyond that and have prefers high contrast.

You could even do prefers low contrast. There's prefers reduced transparency. There's a lot of these user preference inputs that we now can hook into and create these different modes. So it's pretty neat to see how you can create these vectors of decisions. These [00:20:00] decisions Channels that can start from your color system and trickle all the way down into every piece of the component, including if we're talking about accessibility, sizing, motion, all of those things are decisions that you can make.

And in this talk, we really want to empower designers to make these decisions as a part of the styling rules that they're sharing with their development teams. So I don't know if that answers it, but those are some of the additional vectors for user preferences.

Those are great and it's so awesome to see that you guys are talking to designers and not just developers, because a lot of times, developers are probably aware of this, but designers aren't, and even just learning that these are things that they can do or that they can ask their development teams to implement, I think is so it's awesome and so empowering for them.

We believe they're the right person to make these decisions. As far as I can see, designers are the most user centered individuals in the organization. And I [00:21:00] want them to know . What is possible for them to make decisions about and how to integrate with their user and how to expand all the ways the user can become part of the experience.

I like to think about like a car, you get in a car and these modern ones, recognize who you are, the seats move back and slide back. The steering wheel can even go up or down and adjust for your body. And then the color scheme goes from dark to light, depending on the time of day. And there's all these things that like in a car, you can see them adjust and it feels powerful, but on the web.

It happens as soon as the page loads up. It's basically the same thing. All sorts of things have shifted for you. It's like you walk into a house and it goes transform around you. And it's Oh, we see how tall you are. Your leg length, you know, you're walking paces. This will make sure that front door is 20 paces away from you.

Really cool contextual stuff that you can do. That's very transparent to the user. They arrive and they don't know most of this has happened. They just start having the experience. And that's what I really like to [00:22:00] think about is people just showing up, having something instantly and miraculously adapt to them.

And they don't have to think about it. They can change things if they want. Maybe you can give them little toggles here and there. But that's just really cool that we can do that for people adjust on the floor. We want, yeah, we want designers to be the ones making these decisions, putting them in their artboards, adding them to their modes, and telling developers, we want this for our users.

And yeah, it's a new vector. It's a new layer. So don't think you have to do all these things all at once. That's the only scary part about all this. There's a lot of vectors. Now you can start small, add these layers as y'all get time for polish or whatever it is that you need to do there.

But yeah, this, there's a lot of cool stuff coming.

And as a DevRel team, we've also, especially this year, have been even more intentional about reaching audiences that aren't already following along with what's going on in CSS and UI. And that is pretty critical because we could have all the features in the world in the browser. But if designers aren't [00:23:00] designing with these new color spaces, or if interaction designers aren't aware.

of these new capabilities, then ultimately it won't get built in web experiences. So we have really wanted to target people who aren't already following along. Also with the JavaScript community, know that a lot of these APIs are going to make their lives much easier. Yet a lot of people who focus on JavaScript tend not to track what's happening in CSS.

So these are two communities that are really impactful for the success of these APIs. And by that, just. People using them, our engineers are working hard to add them into the browser and not just Chrome, but also in Firefox, also in Safari. And we just want the right people to hear the message to help them do their jobs easier and make better user experiences for people who use the web.

So that's all we want.

It's a small want.

Just a small goal.

So [00:24:00] one thing that I wanted to talk about was when you were talking about responsiveness and kind of the mental model for users, one thing that was touched upon that really doesn't get a lot of talk. and airtime is vertical rhythm. So I was hoping you would talk about how that mental model has shifted and changed and hopefully improved.

I'm so glad that demo resonated with you. That was a huge topic for me in design school. I remember people trying to do it on the web for years and years. And then all of a sudden we got the line height unit. And it just unlocked it and now we're able to make these demos that are miraculously aligning your text everywhere from elements that you didn't think could share a baseline.

They're sharing baselines across all these different areas. And then my favorite discovery, this was like an accident as I was building the demos and I just like to test my demos and right to left and Japanese vertical right to left. All these different modes. And I was like, Oh, we have vertical rhythm [00:25:00] in, and it's gone horizontal.

I was like, it's no longer vertical. It is now in a new direction. I was like, the web is so cool. All I did was use this one unit and use logical properties, which is another thing we should probably talk about at some point, I'd love designers to be thinking more about logical properties. Pause the rant.

I was like, I could feel it swell. It was like the swelling rant of logical properties is coming now. It's no, it's cool. It's cool. But yeah, vertical rhythm, we have it in multi directional multi contextual. So you can bump the font size up. You can bump the font size down. You can change the writing mode to right to left.

You can do whatever you want. And the rhythm remains what it was. Why does it feel like I'm about to write a song? 

The rhythm remains.

But yeah, what's your experience with vertical rhythm and what would you like to see or test out that could possibly be done now on the web?

Yeah, I mean, it's just amazing to me that with so little CSS and so little logic behind it, we can make it [00:26:00] accessible for people who are reading, like you said, to left, left to right in every direction with. Without really having to think about it. That's amazing to me.

It was cool to see Japanese lined up. That was awesome.

I love that demo. If you haven't seen the talk, check it out because it is a really cool demo on Adam's site, or just go to his website, nerdy. dev and play with it live because logical properties have been around for a long time cross browser. They're pretty well supported.

And that's another vector for this. It's responsive to the user and their writing mode, their language, their needs which I forgot to mention because I was thinking user preferences, but it goes beyond that. But also there's a lot of new updates in logical typography too. So still early, but in Chrome is this new feature called text wrap.

TextWrapPretty, which let the browser decide the typographic layout. And TextWrapBalance essentially says, I want usually a heading, so a small piece of text, to be as uniform as possible. So [00:27:00] if you have a long string of text and then just one character or a couple characters, it'll think about what the 50% mark is, it'll bisect it, and then it'll rearrange that headline so that it's even.

And earlier you mentioned Design School. Adam and I'm like, yeah, that's the one thing that annoyed me in design school was orphans and widows. And now we can just put TextWrap Balance or TextWrap Pretty. You probably want TextWrap Pretty for this. On all of the paragraphs that I want or on all of my text and that makes it so much better.

TextWrap Balance is really that 50% bisect where TextWrap Pretty just looks for Making sure there's no standalone words for the most part, but it does a little bit more than that. It's just two different algorithms. And these are two really cool APIs because they're really easy to progressively enhance.

Where right now, your user's probably getting the experience where you have some standalone words and in your typography. So you could just add that line and when browser support grows, they'll get that enhanced experience. It's just one little thing [00:28:00] to make the web look just so much more professional, just like a little touch.

So I love that one.

Let's talk a little bit about interface responsiveness, since we've talked quite a bit about users and their devices. When you started to talk about interface responsiveness in the talk, you described it as playing 4D chess, and I would love for you to talk a little bit more about what that means, because that, even to imagine it, starts to break my brain.

Yeah. I think this is like a, when you start to build this way, you can really see how things add up. So in this talk, we show container queries. And one example is Starting out with the most basic element say you have a responsive card and then, sorry, an even smaller element that is a button. So within that button, you can have a responsive icon.

That icon can adjust how it appears based on how much space it has. Then the whole button can appear combined with that icon based on how much space it has. You can then put that into... [00:29:00] a card, for example, and that card can be responsive and have a responsive layout, then that could be in a list of cards that could have a responsive layout that list could have context.

So we can combine style queries and modes with all those cards, then you could layer that on top of user preferences, sizes, Colors progressive enhancement for users. So all of these little pieces grow and build and build on top of each other. And when you combine that now with something like has where now that card can have its own logic based on its Children.

or the state of any of its siblings or its parent, you can see how this is really starting to now expand. So that's why I call it 4D chess, because you start with these small pieces, but you get an exponential number of possible designs out of it and possible layouts and possible visuals out of it by making these style rules as you go.

So I think it's pretty cool. It's like creating these rules. You don't know what you're going to get because everyone's experience is different. [00:30:00] Everyone's screen size, user preferences are different. Everyone's user account status is different. So if we're talking about like an inbox or some kind of personalized experience It's that's the coolest part about these is we can create these rules, make sure it looks good and bulletproof in any context.

But all those contexts are so unique, that you start to layer these capabilities.

I can just see it mushrooming in my head from, icon to button to card to image to larger and it's really, it's a really cool way to think about things and it opens up so many possibilities, I think, for getting even more specific and user targeted that we've ever been able to do before, which is awesome.

Yes, the personalization of the web. And this is another huge change in responsive design, because before you had layouts that could shift in between two views, and you might have, you know, like your tablet or midsize view, you [00:31:00] Change based on its current screen size. There were a couple of things like grid that had responsive aspects to it.

You could use media queries. So you had a various number of permutations. But now that number of permutations is exponential because of all the components that can be responsive within those layouts.

So let's talk a little bit more about container queries because it is something that I've used a little bit in my own development and I love it. It is like mind blowing how awesome it is. Grid is another thing. I'm so excited for when subgrid comes and is supported in all browsers, but let's talk more about, how are container queries for people who have not had the chance to use them, that how are they more effective than media queries and how do they help.

Change the way that we think about design, the way that you're describing.

So with media queries, we have one input and that is The viewport or media settings or device settings. That is effective in a limited [00:32:00] view of how we do response design today. But with container queries, we can actually look inside the page. So this is a capability we never had before.

Where with container queries and with style queries and hopefully in the future with state queries, we can look at the context of any element and make styling decisions based on its internal context. So it's a much more fine tuned tool than something that's as blunt as just the entire viewport or media information.

And that's what enables this sort of 40 chess analogy of component design and interface design.

I'd say all of your size queries can be replaced with a container query. You can't replace your media queries for the preferences of the user and the orientation of the device, portrait or landscape, but you can replace every single one of your with queries with a container query.

It's more relevant to anyway, and it will grow with you as your application grows and fits more form factors. I think it's even how a lot of us were [00:33:00] thinking like mildly. We're like, we wish is what I was querying. And so now we can't query it. And so that's why I like to think that almost all of your size queries can swap.

Yeah, you could definitely do that. I still like media queries to think about like macro layout of the entire page because it changes the paradigm from component based design to layout design for viewports. So I still like using that separation of media queries for what the entire page looks like. And you're probably using grid layout and thinking very high level in that regard.

And then anything within the viewport, anything beyond that. Point should be a container.

That's a good way to approach it. You also mentioned briefly style queries. How did those interact with containers?

Well, Each container can have in the current implementation is custom properties that can be queried, which is a lot like creating a variable that holds some sort of name. That's meaningful to you and your team and your container can query that Value and [00:34:00] say, what is the value? What mode should I be in?

And it's like landscape mode. You're like, ah then I will create a grid this way. And so it can query these values changing itself or children can query the value of a container. It's also worth noting that container queries you can target a specific container by name. They can be a distant relative uh, or you can just say, Hey, my nearest container and let the browser figure out what the nearest container is.

And so this plays into style queries too. You can say, Hey, what's the body container style? Does it have custom properties on it that I need to toggle and adjust myself to? Also, what about my card? What is the style queries that it has? And you can combine these things together. Ask these values for now.

Style queries is just what is the value of a variable, but it will have more superpowers later. The ability to ask what is the background color? If the background color is black, then I will change my text color to white. You can also kind of secretly do that with custom properties right now. You can be like, what's the value of the BG var?

[00:35:00] The BG var is black. I'll make my text white then. That's like my little current hack to get around like asking it for some computed value. I'm just like I'll just make a custom property and then I can bypass waiting. So yeah, it opens up all these different possibilities for you to define things in custom properties, ask a value, and adapt.

Custom properties are the way. And that piece is spec'd right now, so being able to query the actual styles that are like background pink. It's not implemented in browsers yet, but another thing that we're thinking about in the future is enabling range queries. So you could say The number of items in this grid is between one and five, and you could have a grid num custom property, and then you could make adjustments to the style based on that or percentages or any other type of value that you could create as a CSS object model property, aka a custom property that you're registering[00:36:00] which is another feature that I really want cross browser.

Safari just announced support this year. It's been in Chrome for a while. I'm really hoping that Firefox implements it because it's a part of interop. So fingers are crossed because app property is pretty critical to the web platform for a lot of things.

Do you want to talk a little bit more about it?

App property basically lets you register a custom property so that you can not just have a string value be the value for that property, which is what happens right now when you register just when you have just CSS custom property set up like dash var colon. value. That's a string. With custom properties, you can make that a color, a percentage.

There's a huge list of syntax types, which then lets the browser understand what it means. And one of the really popular demos is, this lets you do things like animate gradients, which let you reach into that gradient and actually have meaning for either the color stops or the color values in there.

What they mean, let you animate individual property values. This is great for things [00:37:00] like, animations or even scroll driven animations with custom properties that you can swap in and out. When you register custom properties, you can also determine if that property inherits or not, which could be a performance optimization if you want it to say this never inherits and you can give it a fallback value.

So if. So if I just say the syntax is color for my color primary, I could set the default value to magenta. And then if I'm using that or updating that value to something that's like a number, it's going to fall back to magenta instead of ignoring the line of CSS. Typing your CSS. So app property and even registering custom properties in JavaScript is like a really powerful vector for typing CSS variables that is just a huge missing piece without cross browser support.

Very cool. You mentioned something that I'd love to talk a little bit more about. You mentioned animations in particular, and one of the really cool things that I remember from watching the talk was linear easing in the browser. [00:38:00] That was amazing. So I'd love if you could talk a little bit more about how that works, how you should, Users and developers can get started with that.

Cause I'd love to, implement that in a website, my own site or some, somewhere else, find some reason to have it. Cause it's so cool looking.

It is cool. And it, it does more than just springy stuff and bounces. But those are, of course, like the going to be the top use cases. There is a cool generator. You can go to, to check it out right now, go to linear dash, easing dash generator. netlify. app as built by a colleague of ours, Jake Archibald, and you can import different curves, different bounces different sort of very dynamic, normally feeling effects.

Preview them and then get the CSS for them because writing a linear easing function is generally, it's almost trying to write your own SVG. You can learn what M and L are, but yeah,

thing at linear easing is there's the linear keyword, which is just from one place to another without an easing curve. But the linear [00:39:00] easing function lets you have an unlimited number of points on the curve. So that's where the generator comes in handy.

yeah, it generates all the points just like an SVG generator would do. You got a curve or something like that. It's going to do all the work. And what those points let you do is they're a blunt instrument in that they don't have any curves at all. But it turns out with enough points, you can create a very convincing illusion of a bounce or a spring effect.

And so that's essentially what linear lets you do. Infinite number of points. It's up to you what you want to do with all those points. And try the generator. It's a good way to get started with it right now today.

Yeah, absolutely. 

Support, this is in Firefox. It was released in Firefox first and then Chromium browsers or Chrome and Edge. It's not yet in Safari.

no,

asterisk for usage.

Easing 

upgrades. 

Exactly. Oh man, that was, that's, that [00:40:00] one just blew me away. Another one that I'd love to talk a little bit more about is scroll link animations. Those were very cool. And if you could describe that to listeners and how they can use those as well.

The big difference between scroll driven animations and regular animations in CSS is instead of looking at a timer to apply the animation, you can now link it to a scroller. You can have a scroll timeline, a view timeline, you can create parallax effects, you can use any scroller within.

The page or the actual viewport itself as the scroller to create these effects and you can do it in JavaScript. You could do in CSS. It's a new API that is also it works off the main thread. So it's more performant to create these kinds of animations. But it makes it a lot easier to just be able to throw in a scroll timeline instead of animation timing to enable those effects.

And it's been really fun to play with. Adam just tweeted this effect where on the bottom 15% of the screen everything Flows [00:41:00] in trickles in with an opacity and it moves up and it just makes the whole page fluid With great power comes great responsibility with this one 

Definitely put that one behind reduced motion. Yep.

So is it basically a way to replace JavaScript intersection observer so you don't have to use that to observe elements and then animate them as they come into view?

Yeah. There's two parts to the API. There's one where, so if you imagine a timeline and you've got like a scrubber that you can go back and forth. The first version of this API is the whole scrolling of your like, let's say your web page from top to bottom. You can imagine that as your timeline and the little thumb that you can grab and go back and forth is the little current position in the animation.

That's version one of this API that's scrolling to the entire scrolling space. And then what you're asking about is more of the view timeline, which is on an element by element basis as it intersects with the viewport. And so what's the percentage of that? So [00:42:00] basically the timeline becomes its lifespan across the screen from top to bottom and back and its position inside of there is just like the little thumb you can grab and you can animate things based on that.

And it does eliminate a lot of. Observer code, but we don't currently have scroll triggered animations. And that means that as you scroll back down the page or back up the page, rather, so let's say you scroll down and something appeared, all of you go back up the page, like to the top of the article, that item would go back to a disappeared state.

So it's very directly linked. Whereas a triggered animation, you'd scroll down the page, it would pop in and then it would stay there permanently, which we cannot do yet. But we're working on it.

Yet.

and that would essentially trigger a time based animation, which is super useful. We said a lot

Yeah. cool. Let's talk a little bit about fluid typography because we talked briefly about vertical layouts and things like that, but maybe you could talk a little bit more about how fluid typography really helps us translate [00:43:00] from mobile to desktop. I know that we've talked briefly about balance and pretty and word orphans and widows and things like that, but there's some really cool stuff that's coming, like the ability to change emoji colors.

Can you talk about how something like that is possible

Goth dog.

You're getting the whole talk now I'll start with just One trick that has been floating around the ecosystem recently has been using something like the clamp function in CSS to set a minimum size, a maximum size, and then an actual size, which allows you to create fluid typography that scales between two sizes with caps.

What's cool now is that you can do this with container queries using container query unit values so you can have that kind of fluid typography, not just on the entire page, but within the page within any component inside the page so we can expand. this fluid typography ability. And yeah, I think that this is one of those things that [00:44:00] helps to resolve.

How do we go from point A to point B? How do we change from mobile to desktop view? What are those in betweens? This is another way to do container query sizing without having to change between breakpoints, but just having the typography be fluid. And the fluid typography right now, at least is linear where it linearly.

Eases from the minimum size to maximum size using the clamp function. But yeah, Adam could talk about color fonts and font variant settings.

Yep. We've got very, I feel like people know what variable fonts are now, and they're aware that they're fonts with lots of levers which is true. And that's what's cool is cause these things are little apps. They have capabilities and they have parameters that you can pass them little options to tweak them.

And some of that means that you can change the colors of an emoji. So we've got these things called color fonts now that essentially are variable fonts that expose an API for you to toggle colors inside of the font. We've traditionally had really rad [00:45:00] fonts that would come out with really beautiful gradient swirls and.

And various effects inside of the font, but we couldn't change that. We'd have to use like a blend modes or something like that to tweak the colors to our own brand or something like that. But now these variable fonts expose the opportunity for you to change each of those gradient colors. Maybe even change the shadows of something or the highlights of something.

And then in terms of emojis, you could change the color of a duck. And so I made a goth duck. I made a duck that was just like, I have no color. I'm so dark, and that was really fun. And I also made a blue duck because that's from Billy Madison. Billy Madison is in the kindergarten class and they're like, hi, Billy, would you draw today?

And he's I drew a blue duck cause I've never seen a blue duck. And I really. Wanted to know what a blue duck looked like. And I was like, we can do that on the web with emojis now and our color fonts. And these are really powerful moments to changing a font. You only have to download the font once and then you get like hundreds of different variants.

I just made a demo the other day for at [00:46:00] Figma with. Another coworker where the user preference for contrast is changing the font. If you want high contrast, I make the font thicker. If you want low contrast, I make it a thin font. When the browser is in a dark mode, I actually changed the gradation of the font so that it doesn't have so much contrast.

It's just really cool little tweaks that I can do to the font without downloading new ones or managing all sorts of stuff. I just interface with this cool, intelligent. Application that just so happens to represent glyphs and characters and stuff. Super cool things happening there. The people that make these fonts are very rad.

They're really impressive amounts of work. And then we, as web developers, we just get to use these things. It's almost like an NPM install, but it's just a variable font download. And you get this whole interface and experience. Anyway, it's, there's a lot of cool stuff in there.

That's awesome. That is something that I'm really not that aware of. We're just using, standard fonts at work, but something that I want to explore [00:47:00] more. That sounds very cool.

Enjoy. There's a lot of fun ones. There's, if you're on Mac OS, the system font is a variable font. It has some cool levers too.

And depending on how many font variants you're using, you could possibly be saving some bytes because you're not downloading multiple fonts. You could just have one font and access all of the different font weights in between. Variable fonts are interoperable between those font weights. You could have more fluid animations if you want to do some.

animating typography. So there's a lot of benefits.

Oh, another cool one too is the, like the. Emoji font is vectors instead of bitmaps. So traditionally like an emoji font would be pictures of emoji, but now the color fonts, since you can change the color of the emoji, you can pick any, gray or yellow that you want to change the emoji because they're vectors, which means they also scale up as big as you want.

So you can animate that when you hover scale that thing way up, it's not going to get all pixely anymore. It's going to look crispy, delicious which makes me want an apple.

Crispy, delicious fonts [00:48:00] brought to 

you 

by Adam. 

So many cool things happening in fonts, but yeah, that's a cool feature that they're vectors now in these color fonts. It's nice to know.

That is very cool. So is there anything in the pipeline over the next year or so for new responsive features that you're excited about and we should be excited about? 

Yes.

I think that the thing I want most is more interoperability with existing features. So that's a big one. I mentioned that property earlier better support, even for things like style queries would be amazing. I think that actually getting scroll triggered animations will be pretty impactful too.

Scroll driven animations are awesome, but that is another tool that we're missing in our tool belt. There's a lot of stuff. And I guess for me, the biggest one would be Browser support having has supported cross browsers. Maybe the most impactful thing because it's such a powerful API. So yeah that's what I would like.

Nice. There's a couple of things I'd like for [00:49:00] responsive web. One of the mistake queries, cause there's still stuff CSS , can't know, that's essentially what you and I are like on a mission to do is give these components more information so that they can make better decisions.

And one of those things it's like. Is this div, does it have a scroll bar or not? We don't know that right now. Like how annoying is that? Like as much as it can know, it can count how many elements it has and it can count how much space it's inside. But then you're like, Hey, do you have a scroll bar?

I'd like to know if you have a scroll bar, I'll add a little shadow thingy. And it's you don't get to know. And we're like, that's ridiculous. We need to fix this. So state queries would expose things like, is it overflowing? Is it, is a child snapped in a snap scenario is the sticky element stuck or not don't make us do hacky observations.

There's a lot of internal state that the browser knows that they don't expose to us. And that's what state queries is on a quest to do is unveil. The protected state [00:50:00] that the browser knows and give it to people and allow them to do cool stuff with it. 

Also, there's a feature called anchor positioning, and we really need to know the state in which the current anchor set is in, and the state queries can help unlock that too. That one is, it's just impossible to style them based on the position they appear in the anchor. That's also an early API, but...

I'm just thinking about how much easier my life would be as a developer if state queries existed because you just hit the nail on the head, Adam, with all the possible things that I could do that would be so much simpler if it was available. And you're right. The browser knows. Obviously. The browser's doing things with it.

Why can't we know?

we want to know. We want to know like another one, a sibling count. How many siblings do I have? Am I the only one? That's the only thing we know right now is if you're the only one, but I want to know what position I am in my third in line on my fourth in line, I'd like to stagger an animation.

So there's like responsive things like that, like responsive to the amount of siblings. We're [00:51:00] working on it. We got yeah, we're 

happy. This is fun. fun. times. 

Sibling count is so nice for prototypes interactions to like, so things stagger in nicely, or if you want variants or gradations of a color theme Oh 

how do you see responsive design continuing to evolve? Obviously these sorts of queries and interoperability. Are there other things that you see, you think are going to become the norm?

I think that the norm will be designing component first and aligning the way that we design and build with the way that we've been architecting things with frameworks already. I think more adoption of these APIs, it's still pretty early, even though there is support in all modern browsers, I think that people still haven't fully adopted container queries and with has that's not even cross browser supported yet.

So I, I do truly think that we're seeing this shift, this evolutionary shift in responsive design starting now, and it will only [00:52:00] continue over time as these things become more stable.

uh, someone described the web once says magic paper. And they're right in that this document, these words, these pictures just magically form fit my device magically do this and that. And it is very magical paper, but I feel like we're at the next level is going to be magical.

Okay. Moments inside of the paper. And that's what we were getting out with all these different things that can affect the paper itself, but also the elements inside there. They need to make and have an opportunity to be just as smart as the paper was. And we're going to have, magic components.

We're just, that's what that's the future is magic components.

Magic. 

That sounds like a good

talk, Well, 

Una and Adam, it has been an absolute pleasure to talk to you today. Is there anything that you think we haven't covered that we should talk about?

View transitions,

If you've got, let's say you got two artboards and you just duplicate it. Let's say you have one artboard and it's got five items on it. You duplicate the artboard, you hold alt you drag it across. You got a second one and you [00:53:00] delete two elements off of there.

You just created two states in a timeline and then flash and all these other tools in Figma, they have smart animate. We've got auto animate and XD. All these things know that something changed and on the web, we've never had a great way of just automating something like that, where the browser just knows that things were deleted or removed and with view transitions, we are able to, on the browser side to do the same thing that you're getting inside your design tool, and it's a really convenient way to work.

And so what you can do as a JavaScript developer, for example, is when someone clicks a button, you delete two elements. And before you delete it, you tell the browser you want this to be a view transition and it'll take a picture of the current state of the list and then you delete two items and it notices that you're all done doing your work because your view transition request has ended and then it goes and takes a picture of the new state which is going to have two less items and it's going to look at both of them for you and be like, ah, I see that two are gone.

Would you like me to crossfade them out? And you're like, yeah, [00:54:00] crossfade those out. And then it's Hey, if you give them a name I'll morph it. I'll do a cool morphe dealie. And you're like morphe dealie away, please. Just like auto animate would do. And so the same way that you've got artboards articulating two states, and then you can tween between them.

That's essentially what we have in the browser with a few transitions. There's another version of this too, where if you think about web page one and web page two, So not just two States of a list, but two States of a page. That's just like having two art boards. Can't we auto animate and auto tweak?

Yes, we can. Yes, we can. And that's the one that we're still waiting to come out stable. We have that one behind a flag and canary. You can play with it's called multi page view transitions, but today in Chrome, and this is a standard that feature that you can use is view transitions with a JavaScript API for single page applications.

It is. Insanely cool. I built a morphing button just last week where I had a button that changes state. Like you click a button, it says like submitting, it's got a spinner. And then it's Oh, Hey, the munchkins are still doing work. And then it's [00:55:00] yeah, that was a lot of work for the munchkins. And then it has another thing like, Hey, I'm all done.

Look at, aren't you happy? And it goes back to a submit button. This morphing button is a really common pattern. And I was able to like three lines or four lines of CSS, make it so that JavaScript just dumps content in there. But before it does that, it says, Hey, I want this to be view transition. And then 

I can make the experience morph. So the size of the button changes and shrinks and grows to the text and the content that's inside of it all for free with a few lines of code and the experiences is greatly improved. And it's Matt, I'm going to blabber all about this because it's so cool. Few transitions.

Yeah. Go check those out there. Rad

It's probably one of the coolest, most impactful features, still a little bit early in terms of browser support but really changes the game for web development and makes it feel super fluid and super native where things are morphing and helping users navigate instead of just completely refreshing the page.

Helps them. Normalize that shift. [00:56:00] So a really cool API to explore. I don't know if there's show notes we could share the links in the show notes to explore more, but Another like key API that's landing in browsers.

Yes, absolutely. We can definitely include links for that for anybody who wants to play around with it and get started.

So if people want to get in touch with you, where are the best places to find you on the internet?

I used to say it's probably Twitter uh, where we're pretty active on there. We share a lot on there. I'm on the other platforms now as well. , If you're on Mastodon or Threads or BlueSky, I do my best to keep up. It's hard in this world. You can find us on Twitter.

You can also find our writing on web. dev and developer. chrome. com. That's where we are writing articles about these new APIs, when things go stable with demos and all that good stuff, so you can definitely follow along there. That, that URL's not changing.

find me on Twitter. I'm S I'm still [00:57:00] there. I'm on blue sky as well. . But I also have a personal website. Check out nerdy.

dev. You can follow my RSS or just visit it whenever you want. It's got a very social networking vibe. So yeah, nerdy. dev or Twitter hit me up.

Yes, and what is your handle?

Oh yeah. I'm Argyle Ink, A R G Y L E I N K.

And mine is at UNA. It's UNACRAV on other things. And my website is una. im. So I also post on there and I usually try to link content as well that I've posted in other places.

Awesome. Again, thank you both so much for your time today. It's been great having you talk to us. Thanks. And. I hope that you have a wonderful rest of your day.

Thanks so much. You've been great as well, Paige.