 So anyway, hi, yes, CSS code. So the thing about code nowadays, I think, is that there's really way too much code involved in building things right away. And not just CSS, it's CSS and JavaScript. Anyone here get really overwhelmed about how they write CSS code? Because the way it is in our organization, so we have backend developers, we have designers, and we have front-end people. And any time in any project, it's always like, the most commits are always from the front-end guys, doing a lot of CSS, so it is very stressful. So there is a lot of CSS code involved in producing anything today. It's just the part of life. And to put this into perspective, I took one of the most, you know, one of the forefront pieces of literature in human history. This is the tragedy of Hamlet. It was produced by some guy named William Shakespeare. I think he's a very famous spy or something. Anyway, so this was produced at a time after 1599, and it was completed sometime before 1602. You know, people aren't really sure because it's been so long. So we don't know how long Shakespeare took to write this, but it could have been up to three years if you were gonna go with those dates, right? And I was really curious, just how long is this? So I fired up my terminal and downloaded it. Did you know it's free to download nowadays out of Project Gutenberg? Anyway, so I downloaded a text file and just to really find out how big is Hamlet. And it turns out it clocks in at something like 34,000 words. Actually more like 32,000 if you take out the copyright notices and all. But anyway, so that's Shakespeare in three years produced 34,000 words approximately. And that's the case for this guy, for William Shakespeare, right? But I'm really curious, let's put it out in perspective if how much code does your average front end guy do in a span of three years, or even just a project, really. So I was really curious on the numbers on this, or here's what I did. So here's what I did with that. Okay, there we go. Okay, so I tried to do the exact same thing that I did with Hamlet except do it with Git because we're in the future now and we have version control and version control is awesome. And it lets you do things like take this and what it's going to do is it's going to just take all the commits of a given author. In this case, I just picked one of my colleagues. She does front end CSS for the most part and filter it by what she does in this folder, the app asset style sheets and then filter it out by how many lines that she wrote and count it in the same way using WC. So what happened was, it was really fast and it turns out it's like 43,000 lines. Oh no, 42,000 words. I think that's like in less than a year. So that's sort of like 1.25 Hamlets that one of my colleagues wrote in actually less than a year for just one project. So yeah, I'm not saying you guys are Shakespeare for writing CSS, but let's just put this into better perspective, it's more realistic numbers. So I took one of the projects that we have today in the world that I'd say is written pretty, you know, it's taken a while to write. So I wanted to see how much CSS WordPress has. It turns out half of WordPress is actually front end code. 76,000 lines is CSS, but if you notice, it's almost just as much front end code as much as back end code, you know? That's a lot of CSS to write. And put it another perspective, the websites today have really huge CSS. Pinterest itself has 1.6 MB and that's in compressed, minified form. And what that means is 47, I tried to uncompress it just to see and compare. So that's 47K lines of code or 148K words. So that's sort of like 4.3 Hamlets for a Pinterest. Anyway, I keep on calling it Hamlets because Hamlet is in, if you assume three point something words per line, then it's something like 10K lines is like one Hamlet, which is usually the point where things kind of break down in CSS. You know, when you write a project, you start with maybe 1,000 lines of CSS, but it gets to like 5,000 and 10,000. It gets really painful. So anyway, that's kind of like my experience to be the breaking point of it all. So we all know this, that the world needs and writes a lot of front end code. And we also do a lot of back end code. In fact, we make just as much front end code as back end code. And we have lots of standards on how to do back end code nowadays, right? I mean, everyone's really opinionated about how to write JavaScript, for example, like how they use spaces over tabs or their line links and all. And people are very obsessed about how to write code properly. So how come people don't really write CSS the way they do programming? Like why haven't they thought it out just as well if we're writing just as much? It seems like we're not up to this level of standards that we would have, and we would expect out of ourselves in back end programming, but in CSS, you know, we don't have those things. But you know what, tell you what, it's not really true. We actually have a lot of history as a human culture to have perfected and you know, figure out how to actually do CSS. Yeah, it's been a while. CSS has been in here for a little long while, and I'm gonna run you through it. Anyway, hi, my name is Rico. You might have found me on the internet, GitHub and all that as our stockers, it's my username, and I'm here to tell you about the future. Well, the modular feature of CSS. All right, so before I tell you about the future, and you know, of course, we have to go back and tell you all about the past. So I'm gonna run you through what happened in the past, I don't know, 10, 20 years of CSS development and how we got here today and what ideas we've all had to get to where we are. So let's go back to once upon a time. Anyone here around at that time doing web development? Oh yeah, a couple of people. All right, well, I hope this is like a bit nostalgic for you. Anyway, long, long time ago in a galaxy far, far away, HTML was written a little differently than how it was today. It's actually still the same HTML. I mean, these pages load the same way in the new browsers, but everyone had different tricks on how to make things look just how they wanted it. We used tables and pixel GIFs that were used as spacers. So here's Apple, which I think it was from 2004. That's actually not so, that's actually pretty fairly recent. That's like 12 years ago. And they're using tables to format that nav bar. Nowadays, we've probably used, I don't know, LIs and floats and Flexbox or whatever fancy new technology, but back then we had tables to format it just like that. It's kind of a shame that everyone was proud of it, but it was actually pretty hard to do. So we had to do things like this just to get a certain text to look the way it is. So there's actually a font tag. I'm sure a couple of people here actually don't know there is a font tag. And I think that's a really good achievement that we've come far and forgotten about this tag. Anyway, so before CSS, this was how people formatted their texts. Fast forward a little more years, 2003. People kind of thought that we're in this cusp of like modern browsers and, you know, there was a big browser war. I won't go into details of that. And eventually they kind of realized and settled, okay, truth, let's settle for web standards and let's standardize how we actually render. And one of the offshoots of that idea was some people thinking, hey, couldn't we use this new CSS thing which has actually existed for a while but no one took it much seriously. But can we use it to separate content and style? So if you notice, the way we did HTML before was like content and style is intertwined. Like you put the actual font names in the HTML and the actual colors, which today if I did that, I think my coworkers would hit me in the head. But back then that was the norm. So what if there was a way to separate them and this was CSS? So, you know, things started to appear to change this into something a bit more palatable. So kind of separating content where this HTML is just all about whatever the text is and your CSS is all about how to format that text. So that was really good. And back then it was called CSS positioning. And nowadays it's just called CSS. But back then it was this new fancy idea, like wow, no more font tags and no more tables. And how did they get away from tables? So a lot of patterns emerged during this era. So people thought of different ways to do things. No more like excessive images. And there were different ways on how to make two blocks of text show up side by side and things like that. That was 2003, that was pretty sweet. So one of the books that were around during that period that really professed this idea was people call it the Blue Beanie Book nowadays. It's on its third edition, but the first edition came around 2003. So Jeffrey Zeldman was not the first person to have these ideas, but this was kind of a milestone, a landmark for this new CSS positioning idea when this book came out, which was around the time web standards was being put forward and browsers were trying to coordinate with each other finally. And eventually that idea got formalized into, hey, each thing, each concern could be separated where in your HTML is just about the content, reusable content, there was even XHTML at that point anyway. So the styling is just in CSS and behaviors in JS. So it's just a perfect separation wherein before it was kind of a blurred, no distinction between one and the other. So one of the wonderful things that also came out of this idea is since HTML is just about content, what if that content was reusable? What if that HTML is just about putting your content there and describing what the content is? So we call this like a semantic approach. So if you have something like, just your standard component that looks like this, probably break it down into smaller divs and each div would have a class that describes what it is. Like it's not telling you it's green or it's rectangle or it's this and that height, it's just telling you what it is. Say it's like heading and then have that defined in the CSS what heading is supposed to look like. And we also tried to use the proper tags at that point. There was this was around a time HTML5 was versioning and we were having all these fancy tags like header, footer and aside. Anyway, so we were moving towards this idea that HTML should be describing the content in a semantic way. And this was called semantic HTML, which all really tied into the CSS positioning movement. Nowadays we just call it HTML, but back then it was a big thing and call it semantic HTML. But there was this, I think one problem with semantic HTML was no one really knew how to write semantic CSS for semantic HTML. And everyone just kind of did the right thing and came kind of a mess. So if you have that same component a while ago, right? So you are gonna write CSS for it. And since we have less and SAS and all those preprocessors from around that time, we started using this nested syntax, which was pretty cool. And it was very convenient and just kind of used it and used it until at some point just kind of becomes this mess. And suddenly, I don't know about you, but this is very familiar. I've landed in too many projects where CSS indented way too far and it looks like a sideways mountain range if you tilt your head. So this was one of the dangers of people not really thinking about how to style their CSS as style their semantic HTML. And this problem is still around today. This isn't like a relic of the past. There's still a bunch of projects that are done this way, heaven forbid. But yeah, we have moved on and learned from our mistakes. Some people have come up with ideas on how to solve this. So this is really tangled CSS, which before you know it, you've written way too much CSS and you kind of get very exasperated. And if I ask a lot of my backend developer colleagues, they would tell me, you know, CSS is your problem, that's not mine. And they all really think CSS is pretty complicated. Anyway, that was 2003. What have we learned in 2003? Separation of content and style is a good thing. So it was around that point that we started writing semantic HTML, which was XHTML and now we got HTML being purposed in different ways. We got SEO and all that and HTML was really taken off in this semantic direction, which is great. But CSS is still pretty hard to write because there wasn't really much of an idea on how to solve this back then. Anyway, a few more years. And we realized that some people have thought like, hey, can we apply the same things that we know in programming and CSS? I mean, at the end of the day, they're both code, right? I mean, once not programming, but still it's code that we type out and maybe we could think about ways to solve these problems in a programming kind of way. So this is a pretty common thing. And I'm just kind of realized that, hey, you have a button that also are other buttons. Isn't that like a programming concept? A programming concept in object oriented programming, which is subclassing, wherein you could get one class and subclass it. Okay, I just repeated myself, but the subclass is basically the same thing with a few changes, which is kind of what those buttons are, right? It's just the same thing with a few changes. Maybe we could apply the same paradigm. So object-oriented CSS was born around this time by someone, Nicole Sullivan, and it was a very interesting concept. Nowadays, you don't hear so much about it, which is a good thing. Let me show you a while later, but one of the best things that came out of object-oriented CSS was to think in Legos. That's actually not my term. She used the term Legos. Components are like Legos. The idea is, CSS was getting bloated and people are writing more CSS than they should, so why not make little reusable snippets of components or Legos that you could reuse in multiple pages instead of having to rewrite them many, many times over? So the idea was to think of your pages in little Legos. And that was one of the great things out of object-oriented CSS, which is still alive today, which is really awesome. So yeah, that was 2011. What have we learned so far, 2011? We've learned that. Separation of content and style is great, and we've learned that components are also great. So it turns out this idea of writing in components tests, outlived OO CSS, it's been also around in many other schools of thought. I'm gonna show you later. So the idea is OO CSS just kind of built on top of what we know about semantic HTML. And later on in the future, other things are gonna build upon the ideas of OO CSS and so on and so forth until what we will have today, which is great, because this is us, like a human society moving forward together. So it turns out CSS is still hard to write. Anyway, that was 2011. A few more years, actually, one year to be specific. We are still writing things in components, which is great. So it turns out that when you take a page, it's actually made up of components in that page. And that component is also made up of smaller components. And basically everything is just components all the way down. And this is kind of how we were starting to think because this is like one of the key takeaways of OO CSS. And we just kind of realized that this whole subclassing idea is still the same thing as components. I mean, they're just the same component. It turns out that it just happens to have a state like a button has hover or focus or active. The same way could have a danger, large, small, wide state. And this ideas were formulated into a book called SMACSS, okay. I don't actually know how to pronounce this. They call it max sometimes, but it was really one of the great ideas that really took this idea of componentizing your CSS and writing a book about it, basically. So this was great. They called it modules in SMACSS, where in this little pieces of UI widgets that could stand on their own are called modules and these modules have states. And the other cool thing that came out of SMACSS is that it started to have this idea that CSS should be written in layers. So CSS has the specificity, I always have trouble saying that word, wherein you could style a bear tag, a class name, an ID, and there's predefined rules of how one will override the other, should take advantage of that wherein you should write your code in layers. Like there's a base layer which tells us the style, the base HTML tag, and there's a layout layer that tells us how to position components relative to one another. And we have the actual modules that are the actual styles, the background colors and all, and we have the states which are overrides for the modules. So basically states override modules, layers override the base. So this layered approach was one of the key ideas of SMACSS, which was pretty cool. And nowadays we still use SMACSS and still refer to it, but idea has evolved. But in 2012 I have learned separation of content and style is still a really good idea. So everything we have so far is still about the same idea of making things more manageable and separating concerns. HTML is about your document, CSS is about how it looks and has to stay that way. It tells us to create a component library just like OCSS and tells us that everything is actually a component all the way down. So everything's just components inside components. And this idea has survived through many years, apparently, 2012, but CSS is still kind of very tough to write, at least for some people. Anyone here thinks CSS is hard to write? Yeah. Okay, I'm glad that some of you didn't raise your hands. So cool. So another year, coming year, okay. So we had OOCSS, we had SMACS or SMACSS telling us that components are great. So what if we took those ideas and turned them into conventions of how to name your class names? So one of these ideas were to name your class names based on what components and what elements are in those components. So basically like this, wherein you have a block underscore underscore an element underscore a modifier. So this is called block element modifier. So this was one of the ideas that really formalized one of the whole marks of OOCSS and SMACSS, which is everything is a component, but how do we write CSS for it? So BEM is like, this is how you write CSS for it. This is how we should make your CSS. You should write really long-conflicted class names, which is great because again, everything is really a component and all those names just basically lend well to BEM class names. And this was also around a time that SAS has been in development and we had this ampersand, I guess it would call it an operator. So you could write CSS very elegantly in BEM, which is really fantastic. So that ampersand becomes whatever the parent is. So basically they just concatenate the two together like that, like that, like that, like that, like that. So CSS was very fun to write in BEM and a lot of people are happy with BEM. A lot of the sites we have today in production that you're going to visit on every day of your lives is actually written in BEM, which is great. Except it leads to some really strange markup which some people are not very happy with but it's one of the drawbacks of BEM but it makes your CSS very nice to write. So that was 2003, 2013, 2013. What have we learned? So the same thing. Content and style separation is still a good thing. I mean that idea has been there since 2003, we're still doing it in 2016. So there must be something to it. So that is good. Create a component library. So BEM is still about componentizing or blocks, thinking in blocks. So that idea has persevered through OO CSS, Mac CSS and BEM. So there must be something to it. Creating a component library where everything is a component and we just kind of realized that CSS conventions are extremely useful. Finally, making that last writing CSS is hard. It's now much easier. However, some people don't like it. So let's move on, see how else we have evolved. That was 2013, move on one more year, 2014. Okay, two years ago. We as a human society have moved on from really slow back ends and realized that hey, maybe we should put things on the front and make really fancy web apps and make the browser do more things than it should. So React.js. There's actually a lot of JS frameworks that came around this era. React is one of the bigger ones that everyone's talking about. It seems like everyone I know is talking about React. And React tells us to think in React components which you could nest. So that same thing could be implemented in React using nested components. So that's all very familiar, right? That's basically how we've been thinking about CSS in BEM and SMA CSS and O CSS. Everything is a component and everything is a component in a component and so on and so forth nested components, right? But it's not just React who asked this idea. If you were gonna do it in Vue.js, also one of the most popular JavaScript frameworks, you would do it pretty much the same. If you were gonna do it in Ember, it's still gonna be the same thing. Everything's an Ember component. So all of these JS frameworks coming out today, as in almost everyone just pick one, even Angular or Ember, all of them, they all work in this componentized methodology. So there really must be something to it because we have been building JavaScript in components just as we have been doing CSS. And that's great because now once you have ideas that have been lingering around for a decade, it means there must be something to it, right? So 2014, we've learned that separation of content and style is great. Everything is still a component and component libraries are great and conventions are still useful. But I didn't really talk about CSS so CSS is still pretty hard for some people. 2015, okay, a few more ideas came, just like one idea coming out every year, actually just like so many ideas coming out every year. Excuse me if I'm just focusing on one idea per year, but 2015 turns out that we are still building things in little components like, this is one CSS component you might build like a star rating, which is actually part of another component. And that component is part of another component. And that component is part of another component. And that component is part of a page. So that's basically what we have been learning through like a decade of progress. And this is kind of like atoms where in, you have atoms which are part of molecules, which are part of materials and so on and so forth. So this idea was formalized in a book called Atomic Design. So Brad Frost wrote an entire book about that idea that I have been talking about for 10 minutes, he wrote an entire book about it, basically telling us that everything is a component and everything is supposed to be written in smaller components, which are put in other bigger components. So that's how we achieve sanity with our CSS. It's how we achieve faster code loading times. It's how we achieve basically how to manage these monstrous 1.6 megabyte CSS that we have today. So there must be something with that idea, right? Cause it seems like all of these ideas are one idea and then the next one just builds on top of what was good of the previous one. Maybe we just card some with a bad and that's basically how things evolve, right? And that's how everything is evolved in technology. We have JS frameworks and we have new JS frameworks coming out, which are basically the same ideas and they just take what actually works and discard whatever it doesn't and move on and for the next iteration do the same. And if JS frameworks has come a long way and we have this idea of components that are in just about every JS framework and we have the idea of components in just about every CSS, I don't know if you would call it framework, but a CSS idea. So there really must be something there because it just persists in everything and seems like everything is a component. So that is great because that means we have now settled into a standard of how we write RJS, how we write our CSS. And no matter what you do, if you choose BEM or any other standard out there, it's still building on top of this idea that everything is a component, which is great. So what I'm telling you is you have to think of everything as components and what we have learned so far, we actually haven't quite addressed the last point yet because for some people, BEM is still kind of rough and it leads to this mess of a markup in HTML that people don't really like. So moving on, 2015, again, there's this little book slash document called RS CSS. It's in rss.io. It's a reasonable system for CSS style sheet structure and it basically builds upon all those decades of ideas and tries to improve upon them and everything is still made with components just like every other idea in the past where you have little pieces of UI, which are components, part of other bigger pieces of UI, which are also components. So components all the way down. So it's kind of like BEM or CSS but it's a little easier to write. So if you remember this component, you would probably do this semantically in HTML like this. Those are class names, basically nothing fancy, nothing like photo card underscore underscore this and that. So it's just what it is. So we're back to semantic HTML ideas. The only difference is, well in CSS, you would write it in the same structure. So if you notice the HTML structure closely mirrors what you would expect in CSS, that's the HTML and that's the CSS. It's basically the same thing. And the magic there is the operator called like this. It's a direct child descendant selector, which seems like a bad idea at first but tell you it's a really good one. Let me just explain myself. So the rules of our CSS is very simple. So one is components are always in two words. So they are separated by a hyphen. So like photo card, search box, always two or more words and elements are just one word. So that's a details heading, title, subtitle, action button. And the variants begin with a hyphen. So dash small, dash large and of course use that. So in practice it looks kind of like this and it just makes things much easier if you have this convention because now so we have like class names in CSS and we don't really know what the class names are. I mean, is this a component? Is this a block? Is this an element? And if you have a convention like this you automatically know if it's dash small, oh, that's a variant. Or if it's one word, oh, that's an element. So that brings a lot of sanity into how you were going to organize your CSS. Yeah, so that's our CSS. In practice it probably looks like this. So if you have a button, probably name it like a button box because it needs to be two words and probably give it a variant for the small one which is part of a bigger component. Maybe call this a call out box and that component has elements inside it. And you could also nest components inside components if you notice button box is a component inside a component which is good because now at a glance looking at the markup we know button box is a component and everything else there is an element without having to really think about it because two words, component, one word, element. Perfect, okay. So the CSS it looks pretty much the same as your HTML. And the magic, there's another magical thing that's gonna happen. So if you save that as one component per CSS file, so if you save this as call out box.scss and every component is just, every component file is just really talking about one component then they don't care about each other. They're self-contained pieces of CSS code and I could just import them all together without really caring about how they're ordered. So it's one of the magics of it, no more like importing every CSS file and figuring out how to load them properly. So one component per CSS file, it makes things a lot easier. So in practice, so for example, if I have a page like this, that is a component which has smaller components that, that and that. And that is also another component. That is also another component. And this is now a component with an element of a tab. And the tab element could have a modifier active which is dash active, also another component. And this one, I haven't really discussed this, just check out the website, but it's called a layout. So it doesn't really tell you how to style it, it just really lays out, it tells you that left should be left, right should be right. And that's a, that's how you would make it as a layout component which has more components inside it. That is also a layout which that button group has buttons inside it. So everything is a component. And that's rss.io. And out of all of these ideas that I've discussed today, starting with rss and going back to semantic HTML, the one idea that really persisted with everything is that everything is a component. We just basically building little Legos that put together more bigger Legos which eventually become pages. And it's been around for, this idea has been around for a decade so there must be something to it. And just to show you where we're going, there are a couple of proposals to HTML and CSS that are also moving in that direction. We have web components which you might know as Polymer, at least in some form. Basically self-contained elements could be placed in external HTML's complete with style and behavior in one encapsulated file that you could embed into other files. And there's also a CSS at scope proposal. And you can't use this yet. I don't think it's implemented but it's in the works. Basically it's letting you scope CSS into a certain something like a class name or any selector and you're assured that it's not gonna bleed into other scopes. So your styles and user profile is not going to bleed into its deeper components. So, if I could just tell you one thing today, it's our always thinking components. And that's me, Rico, also known as Arsta Cruz. And thank you so much. Oh, well anyone have any questions? Suggestions, comments and anything else? So, hello. Hello. Here, in the back. Hi, hello. Hi. I personally, I use BEM in production. I use BEM in production. Okay. But one of the problem that I have with it is, say I have a parent component and a child component. So where should the glue be? So the glue between this reusable small component and the parent component. So where should I write that? So you're having trouble nesting the components? So say header is there. Say header is there. Header component. Header. Header of a page. Hello. Hi, yeah. So say there is a header of a page. Header component. So and I have a search bar inside it. Both are components, reusable. But where should I write the CSS that binds both of them? It should be in the search bar component or the header component. Oh, so you basically have two components that sort of belong together, but you don't know what should. Where should I write the glue between them? Between. Oh, the glue between them. Yeah. So like, say for example, like a Facebook like button and a like count like that. Yeah. You want to glue them together in JS or no, no, no. So in CSS, I have a search bar. Right. So it is nested inside a header component. Okay. So let's say for example, the parent child relationship CSS, where should it rely? Where should it decide? We should, should that CSS be in the file of search bar or should it be inside the file of header? So I'm having a little trouble understanding, but say for example, I think you have two components which kind of belong together and you want to glue them together, but you don't know where CSS would. Maybe let's go a little bit offline. Where CSS would belong. Yeah. Hey. Yeah. So let me try anyway. So how I understand it is, say you have a Facebook like button and a number of likes. So those are two components, but they belong together. But now where do you write their code? So in our CSS that would be like, this is one component, the like is one component, like like button and like count. So their styles would belong in like button.css and like count.css. And that like container is another component, most likely just a layout, which will have like, which would have its own CSS file. Sorry. I hope that answers the question. How do you call? Hey, how are you? Where are you, man? Hello. Hi. What can I do for you? Great talk. I have one question. So usually in our daily lives, a lot of people write CSS, right? But reviewers always go with the thing that, okay, if the page looks proper with the what content has been given with what designers are done, okay, it looks good. We can carry on with the production. But there is no tool to assess the quality of CSS code being written. So what can you do about that? Okay, I have a couple of suggestions. I'm gonna guess you're like a shop that builds many projects for different people, right? And you have designers and developers on staff. Am I correct? Yeah. All right. So we also have that set up in our company and each project has one designer slash front-end developer, the same guy. So the problem is he would send out a pull request or please review this, but then again, no one could actually review it because he's the only one who knows about CSS in that project. So one of the ways we do that is even if one project has one designer, we have another guy come in as a mentor to that person and essentially that other person is gonna review their code. So that's one way around it. Number two is there are actually tools that lets you review CSS code. There's say for example, SCSS lint which tries to enforce certain conventions into how you write your CSS, at least your SAS CSS. So there is that. And yeah, so yeah, there are ways around it. I hope that answers your question. Okay. Thank you. Yeah. Sure. Here you go. Hey. I had a question regarding RSS CSS. So is there any backwards in compatibility or anything to do with this? I mean, it's more of a convention, right? Rather than something new that you're trying, except scope, I guess. Scope being something that's only supported in the more modern browsers. Oh yeah, yeah. Well, at scope is not part of RSS CSS or BEM or anything else because it's, yeah, as you said, it's just a proposal that hasn't been implemented yet. What about the rest of the project? Is that something that's supported by even the site feed? Which one? Like the rest of RSS CSS. Oh, of course, of course. So the child descendant selector, the only browser you will have a problem with that is probably IE6. So probably not a problem. Yeah. Like I guess the selector has always been a questionable thing in terms of performance, right? Ah, performance, okay. Right, so here's the thing. Writing two classes together versus writing a class child descendant class. Usually the one with the child descendant is actually faster because it doesn't have to traverse all, the CSS engine doesn't have to traverse all the way back just to find if this is an ancestor of this. It just doesn't have to search that far. So it's actually a pretty good performance choice. However, it does concede that in BEM since it's just using one class name that's actually faster, but in practice I've seen sites built in RSS and similar that are really big, like one MBCSS big and it's still manageable. It's not something that is really that big of a problem nowadays, especially with better hardware. But yeah, in short, it's never been a problem in performance. Yeah, sure. Okay, if anyone knows us, any questions, I'll be around. Yeah, please take all your other questions.