Una Kravets from Google Chrome
This post is the transcript of an episode of the Design Systems Podcast.
Chris Strahl:
Hey, everybody. Welcome to the Design Systems Podcast. I'm your host Chris Strahl. Today I'm here with Una Kravets from Google. Una, tell us a little bit about what you do there. And I got another guest here that I'm going to introduce in just a second.
Una Kravets:
Hi, thanks for having me. So I am the lead of the CSS, UI and DevTools Developer Advocacy Group, which is the best job in the world. So basically what we get to do is envision the web that we want to be able to build for, and then help engineers at Chromium prioritize and create the APIs that developers actually use day to day. So we do a lot of community feedback. We do a lot of working with the actual specs themselves and making sure that when engineers are writing syntax and specs, it makes sense and is easier to use. So it's sort of like a very intermediary role that is a mix of PMing and community management and content creation and education around those APIs. And then also just trying to get the community leveled up in our product area, which is visual web design components UI. And then the tooling for those things. So it's a bunch of stuff that I loved to do before it was even my full time job, and it's super cool to be able to get to do it with the team now.
Chris Strahl:
Awesome. Well, thanks so much for being on. In the prerecord jam session, I realized that I haven't written production code in like a decade. And so I was in a situation where I felt a little out of my depth on the tech front. And so I invited one of our senior product engineers at Knapsack, a Chris Bloom. Chris, welcome to the program as well.
Chris Bloom:
Thanks for having me on. The web is very different in the last 10 years I think from the last time you were slinging some code, and I'm really excited to be here today with Una. Una is one of my dev heroes. In fact, I've read so much of Una's content on the internet. It's a honor to be here and joining this conversation.
Chris Strahl:
Awesome. So I get to have the privilege of you guys that understand this world educating me about what all this new stuff on the web is about and how it relates to Design Systems. And so I get to play the useful idiot in the conversation and ask a bunch of basic questions to understand what this is all about. So the real focus today is on this new thing that when I started talking to folks about it, to do some research before the show, I got lots of Arthurian metaphors around like, "Oh, this is the Holy Grail. Or, "Hey, welcome to the Promised Land." And this is container queries. And so I want to understand why this is the new sliced bread for the web.
Una Kravets:
I love that analogy, the new sliced bread for the web. Yeah, so that's a good question, especially for people who aren't writing code day to day. But I think that container queries specifically solves a lot of frustration for of developers. It's one of the top requested features that we've heard year over year, and there have been a few changes in the engine, the engine of the browsers that we use today that enables this to actually land. So right now, are you familiar with responsive web design and media queries?
Chris Strahl:
Yeah, totally. I actually worked on a project with NBC trying to figure out how to do responsive ad frameworks way back in 2008. And so that was actually probably the last time I really wrote professional code.
Una Kravets:
Yeah. So with media queries, we have a global viewport, a global entry point from which to query the page and make style adjustments. So if your viewport is 800 pixels, you could have a minute max. You could do that traditional response of design where it's viewport based. There's also media queries and other preference type queries that let you query not just the size of the viewport, but other things, like if it's a print of your page versus the digital version of your page, like screen versus print media. If it's in a dark theme, if the user prefers a dark theme, it prefers color scheme. So there are preference queries as well as size queries. And what container queries enable us to do is not just rely on the global viewports and the entire page from a macro perspective. They let you actually look at a container's parent or a container's parent's parent. It's pretty cool how you could query up the chain and let you set styles on an individual component. So now you can have really encapsulated, specific styles that make a component look good anywhere regardless of where it lives in the UI.
Chris Strahl:
Got you. So give me a practical example. Because where my head goes with this immediately is I'm used to thinking about things at a page level, right? So my page viewport width is 1800 pixels or 1600 pixels. Now it's 1000 pixels or now it's 600 pixels. How does that layout and the containers within it, how do those shift? Now that different based on what you're saying, because now I'm not actually caring about the page, I'm caring about the relationship of that container to another container somewhere else. So give me a little bit better sense about how that works in a practical sense. What would I see or understand as a developer working with this?
Una Kravets:
Sure. So say you have a card, and that card contains... Say it's a blog, right? You have a card that has an image that's a preview image for the blog, a hero image, a title, some text, some tags. So if you're using media queries, then maybe on your blog page, you're adjusting the style of what that might look like on mobile versus desktop. But what if you wanted to then put that in a sidebar or on your homepage or somewhere else? So now you have to go to the home page and manage what it looks like there. You have to make sure that it looks good, say you have it on a highlights page somewhere else. But if you're using container queries to style that card, you could have it live anywhere. So you could have that in the sidebar or the hero, or you could have it in a responsive grid and because you can create responsive grids where the grid itself has varying styles of flexibility, that card will shift and adjust its styles and presentation based on the available space. So you can do this with widths or with styles, with height. It's pretty flexible with spec so far.
Chris Bloom:
I want to share an anecdote here because being in an agency and having built a lot of sites, and having worked with a lot of designers in the past, there was always an assumption from a lot of designers I worked with that this is the way the web always worked. We'd always have conversations around like, "When the card is this wide, I want the button to shift over here." And it was always a very awkward conversation of kind of being like, "Well, actually we can't do that. That's not how it works." And it was always a surprise, like, "Wait, what do you mean? What do you mean I can't?" "Well my designs say, 'Hey, when my card is this wide, I need it to do something different.'" And we'd have to like roll in some shims, there were some JS polyfills for this way back that were very, very heavy and pretty brutal.
But it was interesting because there was an assumption that, "Isn't this the way the web was supposed to work from the beginning?" And we had to say, "Oh no, actually it's just the window. We really can only control stuff on the window." And then the awkward conversations that would happen after that. So it feels like we're finally getting to the point where assumptions about responsiveness from folks that might not be as technical, we're arriving there, the web is evolving to get there.
Una Kravets:
Yeah, and if you think of this from a design systems perspective, it really enables you to create encapsulated styled components that are able to live in multiple environments. And that's something that we did not have before, that encapsulation ability, people have written so many various JavaScripts plugins for this sort of thing and it just is very heavy. So having the browser be able to do that really enables a lot more customizable, responsive design components and design systems as a result.
Chris Bloom:
And there's kind of a dirty little secret about the internet. Whenever you see... Generally you'll see embedded examples of components, the frameworks, all the various CSS frameworks that are out there, tools that we use for design systems building, they always put the demo inside an iframe for a reason, right? And the reason is we need to have that thing respond a little bit differently so we got to give it its own little mini window to kind of fake that component responsiveness. And we talked about the Holy Grail at the beginning of this and it feels like finally, we might not have to do that in the next months or years.
Chris Strahl:
Yeah, so that brings up a good point. So how are people solving this problem now? Because I've definitely seen where you're able to do some really interesting stuff, where you're able to basically say like, "I want to change the way that a button behaves inside of a card. Or I want to change the way that an image behaves inside of another container." Or something like that. And then I've also seen like lots of horrible examples of this, like grids of heroes and things like that that you probably don't ever really want to do. How are people doing that now? And what's kind of changing as a part of this? Is this all done with polyfills and sort of Frankenstein's monster solutions? I guess what I'm trying to ask fundamentally, is this a steer or is this a veer into a different lane?
Una Kravets:
Well, I don't know about steer verus veer, but the way that people are doing it now is mostly through media queries. So it's just like a little bit more of a blunt tool than is needed. So, as you were saying, if you wanted to restyle a card or a button within the card, you only really have the entry point of the page. So you are looking at it from a layout perspective. You can't really look at it from a component level perspective. And the few, and I say this is very few, companies that do look at this from a component level perspective, have JavaScript frameworks that are doing the re-rendering and reading as the page size shifts and then those component shifts.
So there are polyfills, there's a container query polyfill, that maybe I'll link to in the show notes or I'll share with you all, that aligns with the current spec. But yeah, ultimately the way that this is working right now is just through a more blunt hammer of media queries. And people who write this code very much are just used to that. But I think once this lands cross browser, it'll feel like a very antiquated solution. Just like we look at floats today, it'll feel the same.
Chris Strahl:
Yeah. So that is the big change then, right? Is that the browsers are going to support this natively. And what does that really represent as an advantage from the way that things are being done now, and like you said, a limited capacity, but still with polyfills?
Una Kravets:
Yeah, well that's the hope. Right now it's still early days. The spec is still being finalized. So it's going through Working Group. It's mostly done. There are just a few issues that are still open and we currently only have support in one experimental browser. So it's not like it's landing tomorrow. It's more of a thing to look out for that cross browser is well regarded as a good idea and hopeful to be implemented. So there's that. This isn't something that can really use today in production. You can use the polyfill in production. So if you wanted to really try it out, I would recommend checking out that polyfill. But yeah, it is a fundamental change in responsive design. It is a new entry point that we previously did not have, that was not possible without a ton of scripting and using that much scripting for something visual is not a good idea, best practice. And that's a really rare thing to see. It's more like a hack than anything to require that much scripting and [inaudible 00:11:09] observer to be able to do these kind of style queries.
Chris Strahl:
Yeah, I love the casual smile when you talk about the hackiness, right? It's one of those things, it reminds me of the web components conversation in the early bits of that, where there was a lot of things that you could do with web components that were really interesting and made a browser support being a major part of that transition, and really one of the big advantages to web components. Is there an analogous idea here of, "Hey, all of a sudden we get this capability that we've never had before actually supported by browsers instead of necessarily done with a lot of ham-fisted code implementations."?
Una Kravets:
Yeah, yeah. So it's kind of like that where this is a capability that we would have supported by browsers and that's the idea, that's the goal. So I think that another way to think about this is it's more important now than ever to have this capability because as we are building component based systems that are usually built on frameworks, this is more common where you have components, the encapsulated styles, and you will usually name space those styles and have them really neat and organized. But the thing that was missing was the responsiveness. You still had to add the responsive styling of those components either with a flex box or grid responsive layout that has responsive native algorithms like minmax function that resizes and you can do this in grid, no media query responsiveness-ish stuff. But that's also very limited to those specs. Now we are actually able to encapsulate all of the responses styles inside of those components, instead of having to do it on a page layer.
Chris Bloom:
You mentioned working with the Working Group, obviously you direct contact with them and you've been there for most of this process. Can you walk us through how does an idea like this go from somebody saying, "This is a good thing. We should do this.", all the way through the spec, all the way through the voting and the revisions before it goes out into Chromium production?
Una Kravets:
Yeah, so that really depends. With this specifically, we've had people want this for a very long time and it wasn't really possible until recently just with browser engine changes. But if you have an idea, so for example, say motion blur or another spec that you would like to see in browser, there is a GitHub org and it's CSS Working Group-drafts, which is w3c/csswg-drafts. And you can just open up an issue. So I don't think that people realize how accessible this is.
Chris Bloom:
Whoa.
Una Kravets:
You can literally open up an issue, add a one pager or some kind of information with ideally an explanation of the current problem statement and proposed solution. And then from there it would get added to the agenda and then would get discussed. You'd have to write a spec for it. Spec writing is pretty complex because it has a specific syntax on how to do that, and I don't work on spec writing myself. I would work with spec writers. But it's really more accessible than people realize to be able to get something that they see as a browser need into the browser. So that's one step of it. So saying that we need a spec, getting the spec finished, going through that process, then we have to prioritize it in the browser to implement it because we only have a limited number of engineers, and then figuring out, "What are top priorities? What are people asking for? What is feasible to build?" And then that process would happen.
Chris Strahl:
So back to the idea of how this impacts the design system landscape. When you talk about the idea of building with components and how container queries really are the answer to a lot of the challenges around, "I've gone and built this thing with this very like well defined structure associated with it. Now I have to make that structure responsive." Give a little bit better of a sense about how this enables people using design systems to better leverage them in the stuff that they're writing and the components they're building.
Una Kravets:
So with design systems, at least what I see today are various components that have options. So say you have a button, you have your warning button, you have your disabled button, you have your action button, you have your secondary button. So those have styles. And what this enables us to do now is add responsive styles. So for example, you could have an add to cart button, and that add to cart button could have a icon of a cart that appears when you have enough room for the cart to appear and then say add to cart. Maybe you want to then remove that as there's less horizontal space available. Maybe then you want to just say add, instead of add to cart when there's not even enough room for add to cart, instead of decreasing the font size. Because you could do responsive font size now with clamp.
So you would be able to store all of that information, all of the variants of how you want that card to apply and to present visually no matter how much space that card has available and where it's fitting. So then you could put that in a responsive component, you put that in a responsive shopping card, where now you have a responsive button inside a responsive card and you never really have to worry about how that interacts with the global viewport. You can use a global viewport to do what it's meant for which is adjust the global style. So adjusting the layouts and adjusting things of where that card lives, and that button lives within the card within the layout and it grows and grows.
Chris Strahl:
There's a lot of complexity there then. If you can basically say at any particular container I can have things that respond to other things, and it reminds me of slots, for example. When you have this idea of like, "I have this thing that exists inside of this other thing, and those two can interact with each other because they're aware of the presence of one another and they can actually share some data about size." But size isn't the only thing, you mentioned that there's other stuff as well. That could create a potentially really complex chain of logic that represents how things appear visually.
Una Kravets:
Yeah.
Chris Bloom:
Well, so this is interesting because a lot of what you've written on this really focuses on the performance and how we can actually see an increase in performance around the visibility features of this and container queries. A lot about what the browser doesn't need to render if it's not visible on a page. Can you help us understand the difference between containment and container queries?
Una Kravets:
Yes. So that is a good question because in order to enable container queries, we first needed the containment spec. And containment basically tells the browser how to render and separate the content that's within an element from the rest of the page. So with containment, there are certain properties, like content visibility, where the browser can actually make optimizations to skip rendering, skip parts of rendering for pieces of the DOM, pieces of the UI that are still existing in the page so that it increases the performance of the load of that page. So four things that have content visibility on them, the browser's not going to render them. You could even set this to an auto feature where as you're about to scroll into them, they will then get that rendering applied. So because of this, those elements will still exist in the DOM and you can still search for them and they are available to the browser, but they're not going to be visually rendered yet on the screen. So then the reason this relates to container queries is that you first need to set containment on a parent and say, "I'm breaking this section of the UI-"
Chris Bloom:
Out of the DOM.
Una Kravets:
Yes. Exactly.
Chris Bloom:
Okay. Yeah.
Una Kravets:
So I want to set a container type of, say, inline size on this section and then I can query it with a container query, so I can have an element that lives inside of it and I can query it. You can also give containers names. So that enables you to, I talked about it earlier, go up the tree of, "Hey, I don't actually want to query my direct parent. I want to query that parent's parent." So that add to cart button example is one where I needed to use a container name where I was querying the parent card and not just the part of the card that the card lived in. So there's different things you could do in this.
Chris Bloom:
Wow.
Una Kravets:
Yes. But containment is sort of the concept where we can break that apart, have different container types, you can query different things for your container, and then you can use that contained element as the thing you're querying.
Chris Strahl:
This is where we break down into the idea of what are the types of queries you can make? We talked about some style based ones, some user preference based ones, some token based ones. What is the breakdown of those and how do those interact differently?
Una Kravets:
So the first one is size queries, which is probably the most similar to media queries, where you are often querying size. Another type is style queries. So you could query like min width 400 pixels, but min width 400 pixels could also be a style. So that could either be a style size of a parent, like if you're querying the size, or are you querying that the style on the parent is that it has a min with 400 pixels. So there was some back and forth about if we need to specify functions for size versus style. And ultimately the current decision is that if you're querying something's style, so if you're querying a font color or... I think it's confusing, but if you're querying min width 400 pixels as a style not a size, then you add the style function wrapper around it. If you're querying a size similar to media queries, you could just put the min width 400 pixels.
Chris Bloom:
The width.
Una Kravets:
Yeah, exactly.
Chris Bloom:
So it lets you delineate on, "Was this written in CSS specifically for that size or does it just to be that way in the browser right now due to natural sizing.
Una Kravets:
Yeah. So on top of that, you can query, you mentioned earlier, custom properties. So you could set custom property values in your JavaScript per se, which is a way to separate your logic and styling. And then you can query those custom property values as a container query. So for a card, if it was sold true, you could do that. And then you could adjust all of your styles based on the custom property value, which in this case would act like an attribute.
Chris Bloom:
That's incredible.
Chris Strahl:
You can make everything rainbows and glitter once you've sold the item.
Una Kravets:
You could.
Chris Bloom:
You're kind of blowing my mind because CSS, there's a reputation that CSS has as not necessarily being a very dynamic language. You write it once, you go out and you let the browser just do what it needs to do. The idea of being able to set all of these dynamic properties and read them later, just the fact that the containers themselves can be given readable human names that are then referenced later on, that's a big step forward. I know we get to do this in things like grid and animation variable names as well, but it's a very clear step forward for the ability and the approachability of CSS for people to write it and make sense of it. That's amazing.
Una Kravets:
Yeah. Good, good. I'm glad that's the takeaway. Not that, "Oh my gosh. There's more stuff. This is so confusing. There's just so much to learn." That's what I don't want, but...
Chris Strahl:
Well, it seems like it's enabling a whole area of logic in your UI that hasn't existed before. And with that obviously comes an order of magnitude of complexity, but also multiple orders of magnitude of capability, right? And so as the web evolves, it's always getting more complex. That's sort of the way that it always works. But the value that is derived from that complexity is where that key is. And I think that it's very astute to think about the idea of how this relates to the way the web is built today, largely with components and largely with patterns, is this idea of being able to have this interplay between the patterns and the variations of patterns that exist and how those ultimately are represented and built by this hierarchy of containers. I think that's a super cool relationship between the code that is powering these things and then the way that the browser thinks about how they show up.
Chris Bloom:
You have this out in the wild on the Designcember site. I just scanned the walkthrough of how y'all built that. I didn't catch, were you able to bring in the native container queries for Canary only, or were you using the polyfill for that site? Because the individual pieces of that site are pure art. They're absolutely amazing. How much of that were you able to leverage via the polyfill or via native?
Una Kravets:
So the art was created by Alice Lee, who's an amazing illustrator, byalicelee.com is her website. And that website does use the native implementation of container queries with the polyfill.
Chris Bloom:
So cool.
Una Kravets:
So the polyfill was actually written, the new polyfill, was written by Surma, who was on my team as a way to make sure that we could use native implementation for this site. And it was kind of born from that project. It was like dogfooding, we wanted to dogfood the API, try it out, make sure that it worked to our needs, figure out the limitations, and then we also dogfooded that polyfill in the process. And especially as the spec was changing, it was a way that we were able to use it and figure out if that was a good developer experience and build on top of that.
Chris Bloom:
Site's great. Check it out. I know it's for December, but I missed it when it went through originally and I've been linking it to folks.
Una Kravets:
We've been meaning to reshare it. So it was a whole 31 days of new content, mostly new or highlighted content that was recent, around UI and design on the web, web development. And a lot of it was around this idea of the new responsive, which is something that I talk about as this era of responsive design that we are entering into. It's a shift. And I think it's the biggest change in CSS and the way that we can style websites since CSS3, which was in like 2010, 2011, 2009, sort of. That time.
Chris Strahl:
Back around the last time I wrote code.
Chris Bloom:
So you mentioned the new responsive. Your page that you have up on web.dev, the Learn Responsive Design page, it's web.dev/learn/design. What is amazing to me is I think about what was the tech that I would mention even just five years ago? "Oh, you need responsive design. Here's the things you need to know." And I've been going through the list of everything that you have listed in these bullet points and these headings, it is light years ahead, just the tech, conversation around micro and macro. It really is an amazing single point on the internet. And for listeners out there, web.dev/learn/design. Go read this. It is a single place for what new responsive looks like and what you have to know to be effective out there. It's absolutely incredible.
Una Kravets:
I don't want people to think like, "Oh no, I need to know all these new things." It's something that you can slowly progressively enhance and create user experiences that work for your users and their needs. And with this idea of new responsive, it's just the browser enabling us as developers to create more customizable, personalized experiences.
Chris Bloom:
That is my next question is where does the line between designer and developer with all of these new APIs and all of this understanding about how these things are going to behave, is it necessary for a designer to code now with what we need to know about responsive? Is there still room for the purely creative non-coding designer?
Una Kravets:
It's funny, we've been asking these same questions for 15 years, right?
Chris Bloom:
Yeah.
Una Kravets:
I feel like there is a lot that is intertwined between code and design, but that's not new. That's always been the case since web development and web design emerged. So I'm not the one to say all designers need to learn how to code. I don't feel that way. I do feel like having a understanding of the canvas for which you are building helps you become a better designer. So I also know that with newer design tools, there is a more of an entry point for responsive styling and for creating more responsive comps. I have a design background, but I haven't really done a lot of visual design since Illustrator, like Figma is new to me. I'm just behind. I'm behind in all those.
But I know that there are more responsive friendly entry points for those programs now than there were in the past. And we're also seeing a trend of design moving to the web. So Adobe had announced they're building Photoshop for the web. We're seeing Webflow, which is a visual GUI editor inside the browser where you can see your responsive feedback. Even things like Squarespace, as a designer, as the person who's building that page, you can see it interact and be fluid. But the web isn't static and that I think is a critical concept for designers of digital products.
Chris Strahl:
Yeah, certainly. Moving away from the idea of digital posters and into a much more fluid medium. And that's one of the big things we talk about at Knapsack all the time too, is the idea of, "Let's create in the medium it's destined for." If you were, for example, a sculptor, you wouldn't want to draw pictures of sculptures, you would actually want to create the sculptures themselves. And so there is this big question related to the whole should designers code or should coders be deputized into a design team? That is the idea of do our canvas based design tools create code for us, or do we make our code more accessible to non-technical users? And there's a dichotomy there that is really interesting. And there are people that are eating it at both ends, right?
There's the idea that I should be able to draw box on a canvas and have that create a React component. And then there's another idea that maybe people should never actually see the code behind their React components. They should just have a list of props and the ability to edit those props and layer them together and create these complex chains of nesting and inheritance that ultimately build things. It's an interesting problem. And I don't think that it's totally solved yet about which direction we're headed here, but it certainly shows that building in the medium that something is destined for actually matters because that's where you get to take advantage of the features and the capabilities. And like you said, the fact that the web isn't a static medium means that it's very hard to model what the behavior of the web is in something that isn't the web.
Una Kravets:
Yeah. It also really depends on what kind of design you do. I think, for example, UX design is much more user interaction focused and is a little bit different than visual design, UI design. So it really depends. And one of my favorite parts of my role actually is getting to work with the devtools team on design tooling for these features. So we're working on how do we visually put in devtools tools that designers are more familiar with and can feel more comfortable and confident playing in the medium for which they're designing and editing the medium for which they're designing. And as we think about these new APIs, we don't want to add complexity and confusion. We want to simplify the problems that people are facing today. So we do that with the actual APIs themselves and the tooling to support those APIs.
It's definitely a balance. I've worked with designers who don't code, and it's really fun because there's no limitation there as well. So the other side of the coin is they're not thinking about the three sizes I should design this for. It's like, "Can we build this fluid component that is amorphous and follows you throughout the page and sparkles?" That kind of thinking I think can only really happen when you're not limiting yourself. So as a designer, learning to code is a really great part of a tool set, but it also shouldn't limit you if you're only thinking about responsive design, where does this fit in a box? Thinking outside the box is very important.
Chris Strahl:
Certainly. There's a lot of lessons there on both ends of the spectrum. And the reality is this convergence is happening and so designers are getting closer to code. Engineers are making more design decisions for the medium than they ever had before. And so figuring out ways to empower people to make it so that it is more interdisciplinary and, I guess, democratized in terms of contribution is a really important step. It's another great relating back to design systems as well too is I always view design systems as that intersection point between design and engineering. And so that systems based approach lets everybody understand that thing in that modular encapsulated way that ultimately represents the building blocks of apps.
Chris Bloom:
Something that's been interesting to me is the rise of systems thinking around design, "Hey, we should have a finite set of things, a finite set of colors, a finite set of components." We ended up with design systems almost before the tech was there to fully support design systems. It's like a concept and it's a process that has arrived, honestly, before most of the browser APIs are ready for it. Things like CSS variables and obviously container queries. It's just kind of interesting, right? It's like people are thinking this way and it has been really cool to see the tech catch up to what people want to do.
Una Kravets:
Yeah, we like to call that paving the cow path. So that's a pretty typical life cycle for tech APIs. It's something that people need. So with CSS, Sass was so popular and people use Sass to solve a lot of the problems that CSS just doesn't have and now we're taking inspiration from those needs and building them natively into the system. I think that we see that with JavaScript too, like jQuery and MooTools and all those tools that people used to need to build websites shouldn't be an additional dependency. We shouldn't ad page load because somebody wants to more easily select something on the page. I think that that trend of people start doing it and then we need the technology to support the people that are doing it is pretty common that we see on the web.
Chris Strahl:
So let me think about some more far flowing future ideas. I always love to talk about what happens when everybody has a design system because that to me is where you start to think about a lot of the really interesting problem spaces. Once you have container APIs implemented fully in browsers, it works cross-platform, what do you tackle then? What does that enable you to tackle as that next step?
Una Kravets:
So as Chris was just saying, we figure that out once we get there, right? So I don't know. I don't know what the future holds. I know that right now we're working on APIs that we currently need for the web platform. So entry points like nesting things, like adding scoped styles natively to CSS. Because right now we're using JavaScript to do that.
Chris Bloom:
Oh my goodness.
Una Kravets:
Yeah. So right now we're focusing on that and thinking about what's next in terms of what happens when you're using the browser, not on a single plane, not in a single screen. Like what happens with dual screens. These are things that we're starting to think about but it's because we have the tech to think about it. So we now have dual screens. We now have round displays. We now have these problems to solve.
Chris Bloom:
The notch, right?
Una Kravets:
Yeah, yeah, exactly. So that's another good example, viewport units and new units for the viewport that don't include the browser Chrome so that there's not the additional scroll down space when you're setting viewport height. Even with container queries, container based units are something that is also in the spec that we've been discussing around setting styles within the container based on the container height and width or max width and those sorts of things.
Chris Strahl:
Yeah, it's all really interesting in terms of where this is all going. I love the idea of things like the ability to span screens or things like the ability to do adaptive color based upon a container that something's in.
Una Kravets:
Yeah, color is another. That's a whole other thing that we're working on too. So we didn't have the monitors that could support these extended color spaces when the browsers were really being born and the capabilities we currently have for browsers. But now that's changed. Now we have cameras and screens that can support a wider color gamut. We might have a wider color gamut need to represent in our interfaces. And that's a whole thing because increasing the color gamut is like increasing the bit depth of everything on the web. And that's like a very heavy operation.
Chris Bloom:
Yeah. Just multiply all that data, right?
Una Kravets:
Yeah.
Chris Strahl:
I can't wait until I have to enable HDR to look at a website.
Chris Bloom:
Oh, it's coming.
Una Kravets:
So your monitor should already be, say, in HDR, but the browser doesn't always have the ability to present a view in that color space.
Chris Strahl:
Yeah, it's definitely one of those things that I understand where all that comes from in the landscape of video games, not as much in the landscape of like when I'm browsing using Chrome. And so it is interesting to think about the idea of what are those capabilities that exist in the world of other visual mediums that you could ultimately bring to the web? I think that's super cool.
Una Kravets:
And even in the browser, it could exist in an image, but maybe that color value is not available to us as a background because it's not an RGB or HSL.
Chris Bloom:
That's really interesting. And it kind of leads us to a conversation around tokens and a spec for the smallest constituent piece of a design. How do you store a value that you then share? I know there is a token spec that's floating around out there. We have this currently as CSS variables, but it's looking like we're trying to be able to define this as pure data and then have interoperability for like, "Oh, okay, well you said your color is this value. How can that be consumed by something else?" Translating that between styles and JavaScript, all these contraptions for the last like eight years to be like, "My primary color is blue. Cool. JavaScript needs to know about it. And also CSS needs to know about it."
Chris Strahl:
And Swift and some random Android XML.
Chris Bloom:
Exactly.
Una Kravets:
I think what's even more interesting is right now people would use hex codes or HSL or RGB, and that is interoperable between Swift and Java and the browser. But what it's not interoperable with all the time is a import into Figma or design programs. So my understanding of Design Tokens and Design Tokens Working Group is figuring out some data structure that works across technologies and products for designers.
Chris Bloom:
That's it. Everybody agrees, "What does it look like? What's a key on an object I can go look for to get this value?" And it gets pretty crazy around typography. Color is a pretty straightforward thing, but that's the big part of what we do is tokens. And I'm really excited for that spec. I'm really excited for that to land as something everybody agrees on, because it's going to make things a lot easier.
Una Kravets:
Yeah.
Chris Strahl:
We'll link that in the show notes as well. There actually is a draft of that I believe is published. That is something that we're also working on at Knapsack. And so something we also care very deeply about is this idea of how do we create these representations in values that work everywhere?
Chris Bloom:
We are building toward that spec kind of like y'all are doing with polyfill for the container query is we're building the product around where the spec is at ideally. And being able to adjust if it changes. But yeah, it's really different than what I was doing 10 years ago, which was everybody was just completely bespoke, there was no consideration for, "What if this is adopted by a wider group? How do we ensure that it's standardized?" So it's just really cool to see that happen in the token space.
Una Kravets:
And spec writing is hard. It's hard to get consensus, write the code. I definitely want to shout out to Miriam Suzanne, who's done the majority of the spec writing for container queries and scope styles and cascade layers, and a lot of these new CSS APIs that are then being discussed in the Working Group.
Chris Bloom:
How does someone become a spec writer? Just a small digression. What is the background and what does somebody have to study to be a spec writer?
Una Kravets:
I think that the best spec writers come from the community itself. So people who write code for a living or have a lot of familiarity with building websites and understanding the complexities and problems involved in that problem space. I think the same thing with DevRel, I think it's important for a good developer advocate to come from the community, have a lot of experience writing code and still be writing code every day. I think I forgot to say in the intro when I was describing what DevRel is, we build things, we write code, we build not just prototypes but these little mini sites even, like a Designcember or we write demos for talks or we are working on side projects or other production applications. So I think that that's really important for just being involved in spec discussions so that you don't lose touch with the problems that people are facing because you are one of them.
Chris Bloom:
Sounds so cool. You did mention at the beginning, it sounds like the dream job and you get to do a lot of... I mean you do get to code, you are also producing an immense amount of content. How do you keep up with that? What does a day look like going from writing demos to writing blog posts to working with the Working Groups?
Una Kravets:
Yeah, let me pull up my calendar.
Chris Bloom:
Oh, no.
Una Kravets:
The fun thing about this role is that it is so varied and it's not just writing code all day. It is talking to the community and engineers and figuring out what are the right questions to ask. I'm in a lot of meetings now, but that's because I'm doing more team lead stuff than I was before. But it's just such a mix. It's a mix of writing content to then produce, whether it's a blog post or a video now. There's fewer conferences so not as much talk writing these days. It's meeting with the engineering teams and the engineering team directors to talk about progress and alignment. It is chatting with people who are writing specs or reviewing the issues. It's meeting with a bunch of people just across DevRel. So yes, mix of content production, and then making sure that developers are getting what they need. Ultimately it is developer advocacy, it's standing up for the developer community and making sure their voice is heard within a browser company. And in my case, that is Chrome.
Chris Strahl:
Awesome.
Chris Bloom:
Awesome.
Chris Strahl:
We're kind of the same person sometimes.
So all this has been really interesting and highly educational for me as someone that's been a little bit out of the game for a while. I feel like the rust literally falling off my brain. I am curious though, what else is coming? So I know you do a lot of different stuff related to Chrome. Tell me more about what is other stuff that is somebody that works at a design system company I should really be interested in.
Una Kravets:
Yeah, so there's actually another new CSS API called cascade layers, which is coming to Chromium 99, which is Chrome and Edge and then Firefox 97.0, and it's also currently in Safari 15.4 beta. So it should be launching cross browser in the next few months to stable browsers, because these are currently the experimental versions of those browsers. This is also a big change in CSS because cascade layers enable a new injection point in the CSS cascade to solve specificity issues like in your authored style sheets. And the way that works is right now in the CSS cascade, if we zoom out, you have different cascade origins from where styles are coming from. So you have user agent which is Firefox or Safari or Chrome or Edge like the user agent, the browser sending styles. You also have your website styles. So like the author of the website, unakravets.com, I write some styles, you land on it. Those are what I'm sending you, what you're seeing. That's what we work in primarily.
But then there's also local user styles. So those are the individual who has opened the web browser could add styles to override your user styles. And that's because they might have accessibility needs or they might have some kind of additional overlay. So right now, the way that cascade origins work is you have your user agent style sheets, which take less precedence than your local users normal style sheets, which have less precedence than your author style sheets, so your website style sheets, which have less precedence than a declaration that has !important on it. And !important creates a new layer on the cascade, a new sort of injection point where it increases the specificity of that declaration and puts it above the other items on the page. That's why I use !important to override styles.
Chris Strahl:
Right. "Hey, pay attention to this."
Una Kravets:
So yes. So then on top of that, if your local user, so if I, the person who opened the browser wanted to have overrides on any styles from the author of the site I'm going to, I could set a local user !important, which would increase that declaration into the next layer. And then the user agent has the highest trump card of importance and they could set an !important style in the declaration. So that's the most specific, highest precedent styles. So with layers, you as an author are able to create cascade layers of your author site styles. So now we're expanding the possibilities for how somebody writes their styles.
So let's wind in to just the site author styles. So now when you have a layered style, layered styles are always going to have lower precedence, AKA lower style specificity than normal styles. So a layer could be a third party code. It could be a reset. It could be something that maybe even utilities or something that you want to be able to easily override instead of having to worry about increasing specificity of something, like you have to post.link.actuallink, that gets really messy of when you're battling specificity, especially when you're working with third party code. I think this is really important for design systems and for using design systems and third party design systems, or even a first party, and then wanting to have your author styles use those styles, but then override them. So you can inject that system as a layer behind your user styles.
Chris Strahl:
Interesting. So does that mean that it's like a graceful starting point or like a sane set of defaults or maybe even a decent fallback? Or is it something that the idea would be to, "Let's really quickly populate a whole bunch of styling information."?
Una Kravets:
I think that thinking of it as a starting point or as a reasonable set of defaults is a good way to think about how to start using them and especially progressively enhancing with layer.
Chris Bloom:
What's really interesting, and just to throw in a little example out that kind of does this right now, the Tailwind project currently does something similar. When all of the styles are generated for Tailwind, they actually give you the ability to inject your custom code, your custom styles at different layers inside of their stack of CSS. It's kind of a very, very minimal small version of this. But it's really, really interesting to see that mentality moving over to that project and then seeing that maybe that's going to... Not maybe. It is going to be in browsers very soon. That is incredible.
Chris Strahl:
Yeah, it's interesting. That's what I initially thought of. Because this was explained to me at some point a few months ago about how there's different points at which you can specify overrides inside of the Tailwind system. And thinking about that more broadly in scope as like the scope of the web, it seems like a good idea.
Una Kravets:
So yes, this could be very powerful, but could also get you in trouble quickly if you don't realize what's going on. You could put everything in the layer and then have it really neatly organized, but the layer will always have precedence and will always have a higher style specificity than the layer before it. So you have a button with a class of alert and you want that to have a background of red. Then if you have another layer in which you're specifying a background of green on the base button tag, the buttons will all be green. Because even if that button has a class of alert, you are having a higher level of precedence in the next layer.
Chris Strahl:
Yeah. Everything highest on the chain has the highest level of precedence then.
Una Kravets:
Yeah.
Chris Bloom:
I absolutely see this solving the need for the teams that need a base style system, a base design system that then they distribute out to all of their subsidiary companies or subsidiary teams to allow them to then theme on top of that off those base. It just gives a lot more power to that.
Una Kravets:
Right. So as long as that company knows that they still need to scope styles properly, this does not solve scoping, they could create these really unexpected outcomes if they just put button and then green, now all the buttons are green, when they want the alert button. So it's just important to know how this works. That's why I think people who are building design systems need to know that this is coming. The other important caveat is using !important with this. So we know that !important inverses the cascade precedence. It's not just about making a style declaration, have more specificity and importance than another. That's how we currently have a mental model of !important, but that's actually not how it works at all. I just did a whole video on this.
Chris Strahl:
It just flips it upside down.
Una Kravets:
Yes. It flips the cascade origin. So yes, I'm currently supposed to be writing a post about this, but instead I'm talking to y'all. Because people don't realize how !important actually works. And honestly, I didn't realize it either until I started really digging into cascade layers because it makes it something that developers are actually interfacing with now.
Chris Strahl:
You have to think about layers like a stack then.
Una Kravets:
Yes.
Chris Strahl:
Where you basically have this idea that every layer's a stack and you can invert your stack by using important.
Una Kravets:
Yes. So the least specific layer would be site@layer. So you would have your author styles that are layered, which have less precedence than your authored styles that are unlayered, your normal styles. And that has less precedence than your unlayered styles with !important. But your layered styles, which have an important declaration on that style key value pair are going to override your user !important styles.
Chris Bloom:
Okay. Okay.
Chris Strahl:
Interesting.
Chris Bloom:
Wow. That is a big mental shift for devs.
Una Kravets:
It is.
Chris Strahl:
Seems like there's an interesting opportunity for a visualization of that.
Una Kravets:
I have one. I have a link. I will send it to you.
Chris Strahl:
Awesome. That's perfect. Well, hey, this has been really amazing. I just want to say thank you so much for spending your time with us today. Thanks, Chris, for joining me and helping me with some technical backstopping on this little conversation. This has been great. Like I said, I literally felt the rust falling off of my developer brain during a part of this chat today. So thank you so much for bringing the useful idiot along and educating me about what all this stuff meets. It's been really enlightening.
Una Kravets:
Thank you.
Chris Strahl:
That's all for today. This has been another episode of the Design Systems Podcast. Thanks for listening. If you have any questions or a topic you'd like to know more about, find us on Twitter @TheDSPod. We'd love to hear from you with show ideas, recommendations, questions, or comments. As always, this pod is brought to you by Knapsack. You can check us out at knapsack.cloud. Have a great day.
