 bridging the design and development gap with CSS algorithms. Okay, what's this going to be about? All right, so this talk is also known as, an equally confusing title, the algorithms of CSS. So I've been giving this talk for about six months now, and slightly versioning it every time I do, and so this is a big evolution, another big release this conference, version 2.0 of my talk. Very exciting. Okay, so I'm going to start with my background here. So CSS, CSS has always been something that comes really naturally to me. So like in my wonderful introduction, I have an art background, and CSS was something I could visually see immediately. So when I wrote code, I saw an immediate result. And computer science is something I did not really encounter for, I don't know, six years of being a web developer until I literally and specifically encountered the concepts in computer science by way of needing to study for an algorithm's interview, which is a very interesting phenomenon in our industry. So I kind of proposed this talk, the algorithms of CSS, as a way of bridging the gap between these two seemingly disparate topics. So there's a nice bridge. And throughout the course of researching and writing this talk for the first time, CSS went from something else like, okay, I'm writing CSS, like this is sometimes annoying, sometimes it's fun, but it's really like, oh, okay, I just gotta do it. And I was learning all this algorithm stuff at the time. And I was like, this is really cool. Like, oh, CSS, like you're not getting there for me. And through the course of this research, CSS went from kind of like this to like, wow. Oh my God, CSS is a miracle. Like, why can't everything be like CSS? So the bridge between these two things and kind of the two sides of this metaphor, so to speak, aren't really CSS and computer science because CSS is very much part of computer science, but it's more like this. So we have these like departments and different disciplines, like design and products, maybe on one side and engineering's on the other side, we're trying to communicate between these two different departments. Or the structure might be kind of like this too. So maybe everything's a little bit different. And according to the title of this talk, these bridges are comprised of CSS algorithms. Okay, all right, let's get to it. So first question, is CSS a programming language? And followed that up with a nice hand-drawn fire emoji. So has anybody thought about this before? Maybe it's a little bit like, hmm, I don't know, interesting. So I posed this question on the best source for gathering data, of course, Twitter. Okay, so this was in March of 2018. I wrote this question and here are my responses. So 50% no, 42% yes, 8% I'm not sure. A whopping 129 votes in my dataset here. So let's keep that in mind. But the responses to this question were really interesting because some people were like, yes, of course it's a programming language. Like absolutely, why is this even a question? Yes. And the other responses were like, I know, you can't call CSS programming. Like no, it's not a programming language. And so it's kind of like, let's stop for a second here and consider maybe there are some opinions being mixed up in this or like, what's going on? This is kind of like politics at this point. So I kind of took a step back and I was like, what is a programming language? So let's talk about this question first. And there's a lot of research about this. There's entire fields of study devoted to figuring out what a programming language is and putting a definition to this. And a lot of the definitions boil down to a language of formal instructions for a computer. So that's from Wikipedia and others. But the point here is like, it's such a broad topic of study, we can't really have a very narrow definition for what comprises programming. So you would soon find programming paradigms in this field of study. And there are two main programming paradigms. So we have imperative, which is the how of programming and declarative, which is what. So these two paradigms are ways of describing styles of programming, but they're also describing certain features in languages. So how a programming language operates. And an imperative programming language is telling a computer how to do something. So you have the presence of what's called control flow where you are telling the computer how exactly to walk through a set of statements and you're jumping around a program based on a specific order. And declarative programming languages do not have control flow. So all of that logic, all of that control structure is baked into the statements themselves. What are some imperative programming languages? Well, this is what we would usually think of when we think of programming languages. So we have JavaScript, Ruby, C++, Python, anything you might immediately think of as a programming language is probably an imperative programming language. Declarative, on the other hand, these are oftentimes domain specific. So they are built to function within a certain context, within a certain domain, because all of that logic has to be baked into the language itself. So we can't necessarily dictate at the type of granular level that you can in an imperative language. SQL is a domain specific declarative programming language for databases. You might know what's coming here. HTML. Sure, yes. That is a domain specific declarative programming language for you're using this broad definition. And CSS, of course, falls under this category. So CSS is a domain specific declarative programming language. 100%. Also, in 2018, CSS plus HTML are Turing Complete. And so Turing Complete refers to the ability to solve a problem of a certain complexity. CSS also has math. CSS also has functions and variables. CSS also has conditional logic via kind of the cascade and media queries. You can absolutely have conditional logic there. So I wanna talk about a specific conference talk by someone named Felina, who's a computer science researcher in the Netherlands. And she gives this amazing talk called What is Programming Anyway? And she goes through her story of researching domain specific languages in finance to realizing that, oh, they already have programming languages. Like spreadsheets are programming and kind of getting the response from the community that's like, that's not real programming. Except one of the core tenants of programming is that anybody can learn it and so anybody can be a programmer. And when we have these really strong ties to math and logic and to the metaphor of engineering for programming, we're actually excluding a lot of people. And I would consider myself among that. I kind of ended up being a programmer and like being a web developer. But my background was in art. If I thought programming was all math, there's no way I would have gotten into coding. So we can kind of explore other metaphors for what programming is. So programming has writing. So I highly recommend watching this talk of Felina. It's excellent. So to put a little visualization to this, programming is a nice green pasture and all of the programming languages are little pools in this wonderful pasture. This can also be computer science except computer science is a lot bigger than this. So computer science is a lot more than programming languages. So when we draw these like really distinctive lines can be harmful. So I posed this question again in November of 2018. I wonder if their results have changed. No. They have not. I did get many more votes in my data set though. This one has 1,376 votes. However, I will point out, this is a comparison of the two charts. The I'm not sure bar has jumped up a little bit. And I think the real answer to this question is like, I'm not sure. So I'd love to see like that be the most, not necessarily yes or no, but it's like, oh, we maybe have to like think a little bit more about what this question is asking. Okay. So now we're going into a sub talk. This is a talk within a talk. Browser internals in less than five minutes. I have a lot of people in the room and this is important stuff. High level from not an expert. All right. Here's me sitting at my computer, obviously. On the other side, we have a server, obviously. So when I'm at the computer, I'm typing things into the browser into the URL bar and I say, hey server, give me data. The server says, okay, here's data. So if we look at some vocabulary for this process, the client would be the browser and we have an HTTP request, which is the request for my data. And the server is giving me back a byte stream. So that byte stream is given to the browser. Here is said byte stream in hexadecimal unicode points as a term. So these are, this is data. This is HTML, CSS and JavaScript in a much, in a decoded format. And when the browser receives these code points they're called, it turns them into tokens. So it parses them and turns them into little figures out kind of which meaningful groups of tokens there are. And then assigns those two DOM, two trees. So the DOM tree, which we're probably familiar with, document object model, that's where HTML goes. And information about CSS is gonna go into the CSS OM. So the CSS object model. How many of you have heard of a CSS OM before? Okay, so not many. It's a thing. A CSS OM, that's where all our CSS is. And those two trees, I kind of think of them getting married and having a baby, even though that's not really how it works. But they result in the render slash rule tree. And this is very specific styling information for every single DOM element. It's essentially a set of instructions for laying out a webpage. Also worth noting, when you hear the term render blocking JavaScript, that refers to when JavaScript is in this set of tokens and when it's parsed and turned into tokens, as soon as the browser hits JavaScript, it must execute the script. So this entire rendering process and this entire flow of creating these trees is halted while that script is executed. So I just wanna put a little context there because that's a term we hear a lot. Okay, our wonderful render rule child tree. Then turns into layout. So layout is kind of the drawing, this recursive process that draws out every single box in CSS. And by box, I mean DOM element. After that, we have paint. So once that layout, and I think of it as like a blueprint, so an outline of our page and those individual boxes are then turned into kind of tiny images. So we have a bunch of different images. So every single box, all the CSS properties relevant to the paint stage are applied. And we have that combination of images. Then composite. So all of those images are then kinda squished together and one big like snapshots taken into one image. So that's the composite step. So every web page you look at is really a big image. That is rendering. I think CSS, kind of how I've formulated it in my mental model, CSS is a domain-specific language for this process. So CSS developers program the layout of web pages or boxes, 100%. I think of myself as a box programmer. Programmers of boxes, this kind of works for me. Okay, switching gears a little bit. Let's talk about algorithms. Little friend. This is a portrait of me in second grade. Some buck teeth. Okay, algorithms, another definition. An algorithm is a well-defined computational procedure that takes input and produces output. This is from a book called Introduction to Algorithms by Thomas Corman that I think is assigned in most computer science classes. And it is extremely dense and I've read the first chapter. But I figured this was a really good place to get the definition of algorithm from. So I like to use this little framework for thinking about algorithms. We have our input, perhaps an unsorted list. And our output, a sorted list, shocker. What happens in between a sorting algorithm? Hmm, let's think of some sorting algorithms. Bubble sort, selection sort, merge sort, quick sort. I decided to stop there. They're similarly named. Let's look at the implementation of a sorting algorithm. Does anybody know what this is? Which sorting algorithm this might be? Bubble sort. Bubble sort's kind of a joke among algorithms people, I suppose, because it's not very performant, but it's very, I would say, the most introductory algorithm. It's nice to learn. So this is our imperative JavaScript. And I'll give this a little heart because we like JavaScript. And we can see the control flow here. So the for loops, the if statement, the manipulation of the order of execution of these statements. So if this were kind of under the declarative paradigm, this is all we would see. We would just see the what. So that sorting algorithm is obscured behind the function call itself, the declarative part. Okay, let's think about a different kind of algorithm. What if we have a tall row of boxes? And I want all the boxes to be in a row here. So as a box programmer, what kind of algorithm might I write to make all these boxes go into a row? We have several options. One, display flex, okay. Float left, gasp. How dare you. Floats still have their place in our world today. Okay, now let's look at the implementation of display flex in my box program. Wow, oh my God. I'll CSS algorithm, declarative CSS. Give it a heart, cool. Nice, I don't have to do too much. Okay, so I think the important part here about CSS and kind of the way we looked at that bubble sort algorithm and the sort call and we see display flex, it's really like this. So our declarative code is at the top tip of the iceberg and it is powered by all of this imperative code that's happening underneath in the browser. So CSS is the tip. C++ and Rust are what's powering our CSS. I mean, okay. So I talked about myself to do some investigating and look at Rust code. So this is perhaps the implementation of flex wrap in servo, which is the rendering engine in Mozilla Firefox. This is imperative Rust, Firefox. It might be that. But it was a very interesting exercise to spend many hours kind of going back and forth between the spec and figuring out exactly where these things are happening in CSS, it's really cool. So where did I look at this? This is on GitHub. Servo is open source, it's on GitHub. And the codebase is pretty new because it's a rewrite of the rendering engine. So it's commented, it's up to date. And like I said, my process was to go back and forth between the spec and the browser source because the spec is literally instructions and a specification for what browser vendors are to implement. And so there are one-to-one relationships between what's in the spec and what's in the browser. Okay, so good for you, Laura. You looked at a bunch of Rust. Well, there's a point. This is when CSS went from like, okay, whatever, CSS to, wow, oh my God, CSS is my favorite programming language. This is awesome. Because every time I would write CSS before, it was more like this. So I don't know, has anybody ever programmed with a hammer or like done something kind of like that where you're like, just work. I have the same six things in the back of my mind I'm gonna try and it'll work eventually. So no. So now I kind of have this mental model for what a browser is doing and what's happening and what these declarative algorithms, so to speak, are doing. So I approach CSS with a whiteboard marker much more. And that involves pseudocoding. So I have a nice pad next to where I work that I just kind of pseudocode out my boxes before I need to do anything with CSS and taking that moment to pseudocode, give it a heart, helps extremely. And I use this framework, this kind of input algorithms output. Or inputs are, this was for a particularly challenging ocean image hero thing. That's all I'm gonna say about it. And I needed to get it in a specific position. And I was like, what is the algorithm for this thing? Okay. And it was lots of stuff. So we had CSS grid, some flexbox, some bar, calc, like all these extremely powerful CSS properties we have access to. What did this look like? What is said algorithm gonna look like? Okay. Here's a big block of CSS. Give us a second. In March of 2018. It's kind of when I wrote this. And when I was incorporating it into my talk, I was like, okay, this is some CSS I wrote that I really broke down and thought about it kind of as algorithms. Then in November 2018, I looked at this code again and I was like, what was I thinking? Has anybody felt like that about their code before? Just like all of a sudden you're like, what happened? Like what happened that this code was so weird? And so I know exactly what happened. And that is that I got a job. So I got a job. And this is my first job in seven years of freelancing. And I'm a design engineer at Penske Media Corporation working on big websites like Rolling Stone and Variety and like 15 others. And it's a totally different set of problems. So of course I look at my code differently. I'm gonna give lots of hearts here because I like my job. And also I wanna make it known that the way I got this job was by making a friend through a WordPress meetup in New York City in like 2014. And there were no algorithms interviews involved. I didn't even apply online. So I just wanted for you to know that that can happen in the real world. So anybody looking for a job, it can be extremely frustrating. You have all of my sympathy, but it will happen for you, I promise. Okay, so next. Prefixing this with a little bit of a yellow light because these are ideas I'm still figuring out for myself a little bit, but I'm excited to share them. So we have our definition of algorithm, well-defined computational procedure. So I think this is what bothered me about my old big block of code. Is that, okay, it could be kind of well-defined. There are parts of it that are very well-defined. Like, okay, flex, we had some grid going on, flex, min width, width calculation, some height assignment. But I think what was getting me is that this is kind of like a long method code smell. A little bit. So if anybody I'm familiar, the long method code smell is when you have a very long function or method or something where there's just too much happening in there for everything to be useful. So it's all locked away in this one function. It can kind of get unruly. So how do you deal with a long method code smell? Well, oh no. Oh, look at that. Look how happy they are. Nice little weird snakes. Okay, so now we arrive at the single responsibility principle. So every one of our little worm friends here can have one responsibility and can go off and do that really well. Another slightly more useful metaphor would be kitchen tools. So we have kitchen tools, like a wooden spoon, great at being a spoon, a whisk is great at whisking, et cetera. I was trying to think of a tool that tries to do more than one thing, and I thought of one. Does anybody recognize this? This is a spork. So when's the last time you used a spork? I mean, for me, not a long time. I mean, I'm sorry, spork, but you're trying to do too much. So it's sad. Okay, so before we get into more code, a quick refresher of some CSS terminology here. So selector is the thing you're styling. Property and value, declaration, rule. I spent many years mixing these up and kind of using them interchangeably. This is the official terms. We're gonna have another definition by me. A CSS algorithm is a well-defined declaration or set of declarations that produces a specific styling output. And by specific styling output, we mean rendering of boxes. Okay, now it's time to look at some general purpose CSS algorithms. Number one, clear fix. Okay, so here's kind of our input for a clear fix. Apply the clear fix algorithm. There's our output. So the clear fix has two floated elements around the wrapping container and clears both of them. Positioning. So I wanna stick the top text there kind of above the block and outside of it, but I want it to stay right there in relation to the white box. Outer thing, position relative. Sticky thing, position absolute. There we go, stick me somewhere. I wanna point out these two kind of flexible values here. So if you were thinking about this as something, I mean, this is pretty rudimentary CSS, but if you were thinking about pulling this out into something else, maybe these would be two values you could manipulate somewhere. Aspect ratio, one way. There are many ways to do an aspect ratio. Okay, this is my friend's mom's dog named Tuffy. And I was trying to think of a good picture for this slide and I decided a fat corgi is a great picture. So here's our aspect ratio algorithm. So the image container is the div that's containing this IMG and it has a border around it. So if we uncomment these slowly, add some positioning. So we're telling the image to assume the size of its container, which has no size because if the image is positioned absolutely it doesn't have any size unless it's parent does. So we add some padding bottom and Tuffy is a little bit squished. So we need to tell the image itself, so kind of the file that's inside that image DOM element to cover the image. I would recommend reading up on object fits. It's very interesting. Okay, cool. And if we were to pull out any values here to be manipulated elsewhere, there would be this two thirds. So that's kind of our aspect ratio. Okay, arrow with borders. Anybody use this one before? Google CSS arrow, copy paste. Yes, this is what you're copy pasting. The algorithm. So borders are really cool. Another one I recommend looking up. Fluid type. So I've been kind of in too recently. So we have a font size, kind of a static font size added to three VW. So that's a viewport width. So that's 3% of the width of the viewport but I don't want it to keep growing forever. So someone on their 24 inch iMac sees gigantic text that might get too big. So I want to put a bound on that at 800 pixels. And so I can adjust this calculation to stop at 800 pixels. So these are our different flexible values here. And we'll take a look at what this looks like just to give you some context. Just kind of see slowly shrinking text, it's subtle and it stops growing at one point. So if we turn this into a monster sass mix in, this is what it would look like. So I pulled out those three different values into something that can be edited or applied differently. So last algorithm here. Does anybody recognize this one? This is fizzbuzz. So fizzbuzz is one of these kind of silly algorithms you learn if you start learning computer science or you don't learn for five years and then go to an interview and they ask you fizzbuzz and you're like, what are you talking about? Why would you ever do this? But you can do fizzbuzz in CSS. That's really cool. And I would highly encourage anyone who receives fizzbuzz as a question to do that. Okay, so cool. That's awesome. All this cool CSS algorithms. But then I'm like, CSS algorithms? Oh my God, Laura. I was like, really? Are you gonna call these things algorithms? So it depends on the day whether or not I'm like, oh, yes, algorithm. CSS is programming, yes. Or I'm like, CSS is not programming. What is going on? So I was like, I need a word for this. Like, what is a word for this thing that I'm talking that makes so much sense to me? And then it like hit me like, no doi. Like duh, we have a word for this. Patterns. These are patterns. So, here's me. I'm like, CSS algorithms. And the rest of the CSS community is all like, all these things. Like patterns, all this stuff already exists. I think it's so interesting when we're programming and we're coding and figuring out stuff for ourselves. It's like the one thing that makes sense to you. It's like parallel thinking in a lot of ways. It's really interesting. So I kind of see what I talk about as CSS algorithms as all these other concepts in terms of structuring CSS and making kind of assigning logic to the chaos that CSS can be. It's like my way of filtering all that through maybe the computer science things I learned. So a CSS algorithm is a well-defined declaration or set of declarations that produces a specific styling output. Yes, we can also say a CSS pattern is these things. So another quick yellow light here. Cause I wanna show a few things I'm working on at work that we're doing at PMC that are kind of along this, these lines of thinking algorithmically about CSS. So first is a pattern for L features. So a features layout. This is a namespace. So if anybody's seen namespaces before in CSS. So this is the namespace for the pattern, kind of categorizing what the pattern or algorithm is. And then I have a specific grid algorithm in here. And this is the documentation for features layout. I kind of was playing around with actually using boxes in the documentation, which works pretty well cause you can easily see inconsistencies in what this specific algorithm is doing. So it's kind of the output of that algorithm. So here's the homepage of ndwire.com which is using these, many of these patterns. And L features is supporting the layout here. One little tiny part of the layout. Lots of other patterns going on. If we look at the markup for this, like this type of CSS and thinking about these algorithms, little like single or specific responsibility packages of styles ends up looking kind of like this. So some things are a little BEM-esque, but then there are other parts where you're kind of layering on these algorithms. And it seems to work pretty well. And again, like a lot of these concepts are mirrored in other CSS architectures and patterns and things. So another one, this is slightly experimental using a data attribute. So this is that kind of general purpose positioning algorithm, if you will, that we looked at before using a U namespace. So the purpose of this algorithm is to glue, so utility glue, glue this little caption into a corner of an image. And we also set a, or kind of expose a custom property, if you will, for the transform. Okay, so this might look like. And if someone namespaces and setting that U glue transform moves our thing over, or a little caption over a little bit. It's kind of like an API, the way this works. I'm like, CSS APIs? And then I'm like, whoa, slow down. I don't know, okay. Cropping, cropping is like a super useful thing to package up to use elsewhere. So in the future, PMC core patterns and PM package, we might have a mix in like this. So this is packaging up that cropping algorithm and making those two values, kind of exposing those two values for use elsewhere. And using SAS, we can generate class names based on an array of data. So any given project, let's say it needs specific ratios, we can add those to this ratios array and generate the class names. And this will be a core pattern namespace, so I can kind of drop this into a website that might already have namespacing. Maybe, I'm kind of like, I don't know how I'm gonna feel about this in a little bit, I think good still, but a lot of code on slides. Okay, so how do you write CSS algorithms, so to speak? Well, let me go through how to write an algorithm as it is described in Cracking the Coding Interview. So first you plan your algorithm on a whiteboard, then you come up with a brute force solution. So something that works. Doesn't necessarily have to be perfect, but it works. Then when you walk through it, kind of figure out the different parts of your algorithm that maybe need optimization, does it achieve its goal? And then you optimize that solution. So if we're programming boxes, we can use the same concepts. So we pseudo code the boxes, plan it out, plan out what you're doing, write some smelly CSS, so this is your brute force solution. Figure out what those algorithms are. So in this walkthrough part, it's like figure out exactly what you're trying to do, what are the core declarations that are providing that functionality, and then give them some names and some selectors. So pull them out into different functionality. And just to kind of mention, there's not one way to write CSS of all the languages that core CSS, there's so many ways to write CSS, and it's so dependent on you and your project and your team. So I don't want any of us to come off as like, you should be doing this, write CSS like this, but consider it. It's kind of interesting to hear your other ideas and other styles. So in this algorithms framework, so to speak, kind of have our component and our output like this. So anything can fit into this structure. And then what's the algorithm? So you figure that out. And if you're having trouble figuring it out, break it down to something smaller. So one specific part of that component, what do you need to style? And so then this becomes more feasible. So transform positioning gets this into a position. So programming in any language. It's kind of like this. Well, not always, but start with, get something on the screen. Like you gotta start with something. So write some code, and then gradually transform it into a beautiful flower. So the idea is like, it's never gonna be, I totally fall victim to this. Or I'm like, oh, but I shouldn't do this. I shouldn't do this. Like just write it. You're gonna change it. It's all gonna change. It's okay. It's gonna be a beautiful flower at the end. And with CSS specifically, I'm going to be careful about how we talk about CSS. So there's a wonderful article by Rachel Andrew called The Way We Talk About CSS. And we say this a lot about CSS. So like, it's weird. CSS is weird. I myself say this. And this kind of translates to like, it's CSS that's the problem. CSS is faulty or like unintentional, not a well-designed language or something like that. And that's just not true. CSS is declarative and domain-specific as we now know. Unique and resilient. So a little homework assignment for everyone. Try to catch yourself when you're like, CSS is weird. Like this is just weird. What's going on? You're like, oh wait, read the spec. So I had this idea for a really annoying app called the Mindful CSS Bell. That would be go off every 30 minutes or something. Maybe it could like link up to your text editor and could tell if you're in a CSS file. And then it'd be like, read the spec. Here's a little worm. I just wanted to have him come back in somewhere. Is it really funny? Okay, conclusion. Back to our wonderful bridge triangle here. So another way to look at this is, so we have engineering, design and product. So the thing is like we all speak different languages. Like completely, we're all really good at different things. So when we're talking about something like, product uses a different word than an engineer would and design uses yet a different word. So when we're talking about what is the bridge between all these disciplines, I think it's the user interface. So the interface or the kind of what we're building is something everybody at a company can point to and say like, oh, this thing, like we're looking at it, this thing. Also known as the front end. So also known as HTML and CSS and JavaScript. I'm gonna say, this is definitely not an anti-JavaScript talk, let me put that out there. But I'm gonna say JavaScript is not really part of the solution in the same way because you can't sit down and learn JavaScript in two hours. You can do that with, I mean, you know, might take a little longer, you know, more or less time for any given person, but HTML and CSS are such accessible languages that anybody from any part of a company can sit down and understand the basic concepts. And so we can come up with a language that points to something specific, like patterns. So like this pattern does this thing, and then we can all talk about things in terms of patterns. So it's really like this, patterns. And then in engineering, you can be like, algorithms. Thank you all so much. Yeah, yeah, yeah, yeah, yeah, yeah, yeah. So. So we have some time for questions. We have a mic runner, so please raise your hand if you have a question, wait until the mic's with you so that everyone on the live stream can also hear your question. I see the mic runner is looking for the mic. Yes, so who has the first question for today? Where are we going to make him run? Not yet. So I have a question I wrote down during the presentation because I know that I'd be nervous getting up here again. So how will CSS algorithms play a role in designing and developing Gutenberg blocks? Oh, okay, this is a good question. So something we've been doing at PMC a little bit is working on including these algorithms, so to speak, are small patterns in like webpack entry points. So splitting these little tiny chunks of functionality out, it's really easy to pull them in different places. So I feel like with, in Gutenberg, if you've played with blocks before, worked with blocks, you have a block.js where you're importing style.scss and you're importing your dependencies. And for any given block, you import the patterns or the algorithms that you're using in that block. So anything working, if there is a separate CSS build for the front end, they can import that same SAS file or that same CSS file. So it could be a future way of consolidating your CSS, because I definitely, with Gutenberg, I was like, oh my God, there's like more CSS files now. And if you really want what you see as what you get, you might have a lot of redundancy on what's in the editor as well as what's in the front end. So in this way, splitting things out, we can have a single partial. Thank you. So any other questions? Yeah, I see a question over here. Hello, thank you for the talk, it was awesome. So have you ever looked into using other algorithms, such as like Cassowary Algorithm and importing that into your CSS and then using that as like a layout? What algorithm? Cassowary, so Apple uses the Cassowary Algorithm to do their layout on their website. So I mean like taking other algorithms and bringing them into CSS and then using CSS to position things on the page. Hmm, I am not familiar with that algorithm, so I don't have 100% of the context for your question. Is this an algorithm that is kind of translated to layout or is it specifically an algorithm for layout? Or is it like, oh, this algorithm does this thing, let's see what that would be like in layout? It calculates a distance between two divs or elements. Oh, sure, absolutely. That's kind of what, I mean I honestly think of design systems as like one big algorithm in a lot of ways. So if you have kind of a spacing system set up in a certain way, I think that would maybe be an all yes, but yes is the answer. Thank you. Yeah. We have another question here in the front. Oh, was another one spotted? Yeah, very good. Sorry about that. I loved your talk about getting that shared language and I was curious, you talked about the engineers and kind of the designers getting that shared language. Any advice on how you bring that third pillar up to speed as you get like a new client to using that language of patterns? I think having a pattern library, it's a good way to start. So documentation, you could even create some kind of nice walkthrough experience. So I mean, I feel like doing agency work would be a real sweet spot for having these kind of patterns and systems figured out internally because then you can just like pump them out, essentially. I mean, with good quality. So I would say taking care to have that step and saying like, okay, this thing on the page, this like collection of three widgets in a row, this is what this is called, period. We call it this. And to make sure there is that one-to-one relationship with what you're pointing to and what it is in the code. Yeah. So let's say you were going to do another repeat of your Twitter poll in a few months. And if kind of that goal was increasing then, I don't know. Like what are the things that make the biggest dent in getting like more I don't know is from either side? Like what are the things that are changing about how people perceive CSS or the changes that are happening in the CSS at the spec level or in browsers? Like what are the things that are changing in the next six months that are going to make the I don't know go up? Yeah, so this is not the last six months, but CSS grid and there's also a spec for like logical properties and values. So there's a lot of declarative logic that's going to be baked into CSS. But even I think grid is just such a great example because it's an extremely well-designed like layout API and layout interface for programming. And I think also Houdini is a really big thing. I don't know if that has anybody same for familiar with Houdini in here? So Houdini is a JavaScript API, but it allows you to create new CSS properties and have access to the rendering pipeline at the paint layer. So you can create your own CSS properties and now there is a CSS API for doing that as well. So you can literally create a new property in your CSS file. Also big one, custom properties. So which are AKA CSS variables. I like the term custom properties though because that is what they are. Yeah, that's what I would say. Good question. So question from me. When I first started learning CSS about 10 years ago, one of the things I really enjoyed was going to some websites that are really pushing the bounds of what is feasible and just CSS with no JavaScript or anything. One of my favorites at the time was CSS Play with just two nickels personal project over in the UK. I was wondering if there are any resources or websites that you enjoy frequently finding experimental new hacky ways of throwing things together. So labs.jensimmons.com, specific answer. So Jensimmons is a design advocate for Mozilla and she does a lot of work with the CSS Working Group, like evolving CSS and also the developer tools in Firefox to accommodate playing around with CSS. But on her website labs.jensimmons.com, she has a lot of really interesting layout experiments. And also keep an eye on CSS tricks. There's always really cool or like in-depth tutorials that come out about like, hey, I did this weird thing. It's like, oh, writing modes are really cool. That's a small, also that. All right, any other questions? Now's your chance. None. Thank you very much for your presentation. Please give her a big hand.