 Okay, hope you had a good lunch, or at least you're not starving anymore. My name is John Albin Wilkins, and I'm known as John Albin, just about everywhere. I'm a senior front-end developer, I work for Previous Next now. That's a Drupal consulting company in Australia, and I live in Taiwan, and this is a picture of me in Taiwan with lemurs that are at a zoo. You know, they're not native there. But one of the things that I like to do is, of course, make free software, right? That's why we're here at Drupal, but I've also done ZenGrids. This is a SaaS system to allow you to easily build responsive layouts. Then there's a normalized CSS for SaaS and Compass. There's this async theme for Colquay, it's an IRC client from Mac. The SVN migrate does, if you have some legacy subversion repositories, convert them to Git. I had like a thousand subversion repositories lying around. Then of course I've done the Zen theme and a bunch of Drupal modules. That's me. Hello. But I'm here today to talk about design components, but front-end development. I've been kind of crazy the last few years. It feels like there's a new thing every other week. There's Gulp, JS, there's Task Runners. We're starting to do a lot of DevOps in the front-end in order to automate our systems. Responsive design, of course, still relatively new. All these things, it's kind of crazy and it's hard to try to see where we're headed when we're just trying to figure out what the heck's going on right now, right? I usually like to start a lot of my sessions with this quote, are you new to front-end development? Here's a secret, no one else really knows what they're doing either. The good news is actually that it's gotten better. I feel like I'm starting to figure out what I'm actually doing. That's why I'm up here. I'm going to sort of give you a little bit of knowledge from what I've learned from being in the trenches. Because I've been able to feel like I've gotten a little bit of a handle of what's going on, I've started looking forward to make sure that we're not going about, hey, look at this cool new thing. It's called table-based layout. I don't want us to go down the wrong path. I started looking ahead and the thing that I see is basically web components. How many people here haven't heard of web components? Basically almost everybody has heard about it. There's a couple of really good, the CSS tricks one is a great article that describes what web components are. Then of course there's the actual spec. It's a very new spec. It's still being built. If you want to play around with it, there's basically JavaScript polyfills in order to do it because I don't think, there's no stable browser that actually has this implemented yet. Basically what web components are is the HTML spec authors got together and they're like, hey, you know what? Web developers, they really like these templating systems. We should implement something like that in HTML. What web components are basically is they've taken this idea of PHP and Twig, all of these things that are templating systems, mustache, all of these things and said, okay, how do we implement that at the HTML level? For example, you can do things like you can create your own tag that is called carousel. It would encapsulate all of the design and the markup within that one tag. You just use that one tag and then all of a sudden it presents all of the designs and configuration within it. Carousel. You're likely it's going to be like, oh, God, why do my client listen to me about carousel's tag? You can do something with web components. What can we learn from this? We have reusable and repeatable components and self-contained design. Within a single web component, the CSS that's specified there doesn't bleed outside it. It's just encapsulated right there. I feel like that's the major thing that we can actually do that now, but without the web component technology part and it'll make sure that we're moving in the direction of the new technology that's coming. Have we done things, how are we doing things, how have we done stuff in the past, and I include myself in this that haven't worked out for us on CSS. I think our biggest sin is CSS specificity wars. This is the only cat gift in the entire presentation, so don't worry. If you like cat gifts, I'm pretty sure Dave Reed is speaking sometime in this conference. What do I mean specifically? You write a selector because these are the classes that Drupal gives you, I thought I changed these. You're styling this particular link inside your menu. You're like, okay, that looks great. This is my main navigation, perfect. Then you realize over the sidebar, I need a slightly different styling because it's a different design. I'll just write sidebar menu item may link, so it gets more and more specific and I'm having to undo styles from the previous rule in my sidebar. Then page 37, some manager decided it has to be different on that page. You keep writing more and more specific and you're having to override stuff and it just gets really messy. There are a couple of things wrong with here. One of the specificities is way too high and it gets out of control and it's because the order that our rule sets are in the actual style sheet matter. That's just bad. You can rewrite this in SAS like this and you're like, oh, this is better, less typing. The problem is all we've done is now we're auto-generating the same awful CSS that we were writing by hand before. SAS doesn't fix this by itself. It's a great tool, but this is not the way to fix this problem. Part of those overly specific rule sets and selectors are also overly generic class names and Drupal has these. I'm sorry to say that I think maybe this one came from the Zen theme title. It's everywhere, block title, node title, views title. If you want to apply a title styling, what does that mean? You have to specify the context in which it means something and this is just, this is crazy and then we have the same thing for content. Not kind of, I apologize for the title one. That's pretty much mine, but the content one, I don't know who did that. Sometimes you just have to accept your mistakes and move on. It seemed like a good idea at the time. I apologize. So today we're going to talk about design components and how to fix those problems that we're having with our CSS and what am I talking about? Component is the same as, there's like 80 different articles that describe this stuff, but it's basically the same thing as object in OOCSS by Nicole Sullivan, module in Jonathan Snook's snacks, block and block element modifier, UI patterns, these are all the same thing. That's what a component is. And the goals of our design components are to reduce the specificity. So instead of having like three different parts of our selector, we want to have a single class selector. We're also trying to reduce the applicability, which means that we're trying to remove that context, the required context, and we get the design we want. We don't want to have to specify context at all like, oh, sidebar, right, don't do that. Just the single component class. And then an improved maintainability. Because we are making it easier to apply design and have it be repeatable, that improves the maintainability a lot. So design component, one class, one consistent style. I don't care where on the page I am using the button class. If I apply that class to a particular HTML element, I want it to have that style exactly. And then we also have other kinds of, like here's some more examples, like navbar, tabs, more link. This is sort of Drupal friendly. These things can be components. You can have a specific design for those things. Here's some other ones. Teezer, side and nav, pager, sort of things. But you can also have, like, watermark, bio, breaking news. What you're trying to do is you're trying to find, you're trying to look, I mean, oftentimes you're going to get, like, a complete page design from a designer, right? And you want to try to look through that design and pick out little pieces that could be repeatable designs. All right, they may not ever be repeated again, but they could be. So, like, main navigation, you're probably only going to have that once on a page, right? But it's still a component. You want to have it, is somebody calling me? Jesus. Oh, it's my wife. Yeah. Thank you. Sorry, Annie. And she's in Taiwan. I don't think she knows what time it is here. Anyway, so you want to have a single, I got to take my phone out of my pocket. You want to have a single class that describes a specific design, right? And you're trying to make them sort of encapsulated and it just does this one thing. But I wanted to talk to you about, like, the semantics of this, right? Watermark, breaking news, these aren't sort of the traditional Drupal ways of creating classes, right? That's because of semantics. I mean, everybody has to have a semantic class, right? Well, this is my little mini rant about semantics. Semantics is the study of meaning. So in order for it to be a semantic class, it has to have a meaning. Brilliant. Amnanam has more semantic than blah, right, because amnanam, everybody knows, a cookie monster, that has meaning. That's a semantic class. So as long as you don't name your classes, blah, blah, blah, blah, blah, I'm good. So our content semantics, that's handled by HTML5 elements, right? If you want to describe your content, you use an HTML5 element to describe that content, you know, article, headings, H1, all that stuff. So let's make our class names that we use for design components to be design semantics, okay? So the class names become meaningful to the designers, the developers who are implementing the design on a, you know, semantic HTML5 element set of markup, right? And the classes are all about the design. Smacks, you've probably seen in a slide like this, like 80 million times. Base layout, module, state theme, actually, who here isn't familiar with smacks? Okay. A fair number of you. So base layout, module, state theme, it's like Jonathan Snooker looked at all the Drupal terms and said, how can I mess with them the most? So module and theme, these are not good names for Drupal people. So I'm going to be using this sort of modified version. We had a big long debate, Morton and I, and a bunch of other people to try to come up with these sort of names and like decide within the Drupal community, this is how we're going to talk about smacks, okay? So base layout, component, state, and skin. And basically this is a way of sort of categorizing your styles. And I'm going to skip over the explanation just for a second because I don't really like the way he's put this into these five things. I'd much rather have state and skin, that they are part of components and I'm not sure why they're giving sort of equal weight in the smacks organization of those five things. Because state and skin are really, they're part of components. So now I'll describe base layout and components of a rescue. Base styling is basically, it's just the styling that you apply to HTML elements. So like if you want to add, you want to style a paragraph, you P and give it that styling. H1, what's the styling for H1s? So all of your HTML element styling, that's your base HTML element styling. Layout, these are classes that you create that are specifically for moving big chunks of your page around to do layout, your responsive layout stuff. So you have like a class that's called layout dash three column or something. And then it's, that is for the wrapper. And then you'll have another class that specifies this is the left column inside that three column layout. So all of your classes for that are related to moving your page around. PixelWhip is giving a presentation later today, I think. I don't know what the time, does anybody know what time it is, his presentation? It's next. It's next, in here? It's next, somewhere. He's giving a presentation just on layout. So go talk to him about that. And then components, these are the design components. This is what the entire rest of the presentation is about. Smacks is really good to start with. And then as you start to implement it, you feel like there's some pieces missing. And for me, the pieces that we're missing were BEM, block element modifier. So basically your components then become these, described as these five things. The actual sort of base components, elements, modifiers, states and skin. I will talk specifically what those are in the next slides. So let's start with, you know, I've given this presentation a few times. This is my first time giving it at a DrupalCon. And I used to like show screenshots, and I felt like the actual web design that was on the screen was messing with people's ability to understand these concepts because they're very new. So I decided to like make a visual analogy. So the design that we're actually going to be doing today is the flower component. So in order to, I want, so I've got the flower class. And any time I use that flower class, anywhere on the page, I want it to look exactly like that, right? So if I've got an H1 element and I apply a flower class, it better look like that on my page, or I've done something wrong. And this can apply to any HTML element, I don't care. It's got to have that design when I apply this class. That's what a design component is all about, right? And no other element is going to have a flower class unless I wanted it to have this design. So instead of having these highly specific selectors, you know, nav, item, a link, we're converting the specificity from the selector into the actual naming of our design. So the naming of our class is the specificity. Okay. So this is the component, flower. So, and oftentimes we'll have, this is the rather complex design. So if we start to look at the individual elements of it, it'll have, like this requires several HTML elements. Just take my word for it. So we start to look at that to like one of our divs or whatever HTML element is going to get the flowers, underscore, underscore, petals. This element is going to get underscore, underscore, face applied to it. So those classes then are applied to individual elements within our design component because we have this complex multi-element design. And I don't want you to think that, you know, these stem and leaves, it feels like leaves should be nested inside stem. Well, I mean, obviously your positioning leaves relative to the stem, yes. So it has to be nested inside it so you can do like relative positioning or absolute positioning or something like that, right? But I don't want to have the naming of the class represent the HTML hierarchy. I don't want to do that. So like I wouldn't want to do flower underscore, underscore, stem underscore, underscore, leaves to show that leaves are have to be under inside stem. If you want to document that the leaves HTML element has to be inside the stem element, you can create a style guide for that. Doing automatically generated style guides is a really new thing that I just started doing. It's great and it's perfect for this, for documenting this kind of things. But don't, I've seen people do this before, don't create flower underscore, underscore, stem underscore, underscore, leaves because you've suddenly prevented me from refactoring this design module so that there's no longer this requirement that the HTML elements must be nested. Because the naming insists that they must be nested, but we can no longer refactor this design component so that they're not nested. So just every single element is just specified using underscore underscore and then the name of the element. And I would like to say that this doesn't even mean that leaves have to be an element within like the flower wrapper, right? I don't even want to suggest that there's that kind of HTML hierarchy, right? Because you can also have a flower bed underscore underscore bed, the flower underscore bed is obviously a wrapper, right? The flower goes inside the bed, right? Well, let's say we're doing like visually centering, right? So flower bed just happens to describe a wrapper HTML element for the flower component. So elements really, they're pieces of the design, but they do not represent any sort of HTML hierarchy. These are a loose collection of HTML elements. Modifier. So we basically have the same design here, but it was just modified slightly. So there's a lot of CSS properties that can be reused, right? So if we, instead of specifying just flower, we specify dash dash rose, it's going to use most of the CSS properties, but then there'll be like an additional rule that specifies how the rose is slightly different from the base component, right? This is a modified variant component from the base component. This is our hover state. State is a really interesting one because states are basically there's three kinds of states. You have states like this, which are hover, active, link, what I wouldn't know, not link, but those kind of selectors. Then we also have JavaScript interaction. So if there's some sort of JavaScript interaction where you click on something and then it adds a class to modify the design slightly, the way that you do that is, for example, we want to have some sort of JavaScript interaction here. This becomes the is-pollinating JavaScript interaction. My design skills are not that good. The flower is meant to look just as happy as the bee is. So that's the second kind of state and the third kind of state is our media queries, right? Those are also a kind of state of our component. This is the desktop design, mid-width 48ms, so it just wraps around just like normal flower, and we get this sort of slightly altered state when the media query applies. And I would like to remind you that print styles, those are also media queries. So print styles, like for example, this is, yeah, there's our print style, pressed flower. Yeah, this is just another kind of state. And then the last part here of our design component is skin. This is something that Jonathan Snuka added to Smacks, and it's not done very often in design anymore. It's usually, like, the skins that they would have, Yahoo, for example, I don't know if you remember this, they don't do it anymore, I don't think. If you went to, like, the Yahoo homepage, it was for, like, yellow colors, and then when you go to, like, Yahoo Finance, it would, like, change globally, everything would be, like, slightly green, right? So it's a way to modify a large set of design components with a single modifier. And I don't have a picture of that. I remember, like, what am I going to do? Make it green and have a money symbol in the middle or something. This didn't have a, it broke my visual analogy, so. But I'll show you an example in the next slide here. So here's what we have, all of these different parts. Component modifier. So you notice that I put a single dash in here. This is why we have double dashes here, because sometimes you'll have a design element that you just can't figure out how to describe it semantically without using two words. So you just put a single dash in between the two words, and that sort of indicates that this is the name of the component. And then we'll put the double dash. That becomes to show that there's a modifier. So an altered version of that same design. Double underscore, then, I mean, that's why we have double underscores, just to be consistent with the double dashes. And n elements, you know, sometimes an element will also have two names or two words that require it. This is our JavaScript state, here, is state. And you can see that there's no space here. This class is, in the selector, both of those classes are on the exact same element. Hover, and then media, whatever your media query is that wraps around it. And then here's the skin, right? So you basically, somewhere on your page, you're applying the skin class, and it's altering all of your design components, you know, globally. So these are the different ways that you specify web components using classes. Go back here. So one more look at this. Base, layout components, and components are broken down to do. Components, elements, modifiers, state, and scan. File organization. I use a file organization that is broken down in basically the first three levels of snacks. So our base styles go into one folder. Layouts go into another folder. Components go into another folder. And that works really well, actually. Yeah, here we go. You can see an example. So I use SAS, of course, so I have my styles.ses file. And then basically it's just sort of importing all the files from base and components and layouts. This is my file structure. It's really simple. These are the only levels of file structure that I need. And the reason for that is because it, surprisingly, you end up with just a whole ton of files inside components. But it's actually really easy to find stuff. It's surprising. It seems counter-intuitive if you have 80 files. How am I going to find anything? But I tried this out for the first time on a project, and then we had another front-end developer come in during crunch time. And he took a look at my files and he was like, Holy crap, what did he do? And then basically he just did this. He's like, okay, he knew that he had to modify this one design. So he looked at the page and he's like, okay, that thing. And then he inspected the DOM, saw that there was a class applied to it, and then he looked for a file with that name in the components folder. And boom, he knew exactly where to modify. He found the exact file he needed to modify. So the file names are the names of the design components. Let me see if we've got a whole bunch of audio button dialogue, engagement badge, feature divider, feed icon. Some of these I would want to change. I'm like, I don't really like the way that works, the way I named it originally. But you know what? It doesn't matter. Do not stress about what you actually name it. You're just trying to give a sort of rough approximation of what the design encapsulates, because it's a visual design, right? Maybe you won't come up with the best words originally. It's okay. You can refactor later if you want to. It's more important to just start building out your site and recognizing the actual component than it is to worry about what the actual name is. And it will take a lot of practice. You'll get better at it as you do it. And you realize that it really doesn't matter so much, as long as you've sort of encapsulated the design. It's not so bad. Here, let's look at the styles.scs folder, or styles.scs file. So I'm importing my init file, underscore init.scss. That's where basically I keep all of my SAS mixins, variables, where I'm importing all my compass modules, whatever third-party library that I need. And then usually I only have a normalized file inside my base styles. So I take normalize and then just pack it up, because I want to make sure that I have some styling on all HTML elements. So I just take normalize and start adding in my styles for HTML elements. And the way that I usually target, or the way that I decide what is the design that I'm going to use on HTML elements, is to think about WYSIWYG editors. Because WYSIWYG editors are usually horrible about trying to insert a class into whatever thing that you've just typed or added to the page. So I just recognize that it's going to insert some standardized markup, hopefully. Hopefully, HTML5 markup. But it's going to be really hard to insert the classes. So what do I want all of my HTML elements to look like? What design do I want them to have inside the body field? And that becomes what I specify in my base styling. And then inside all my design components, they're overriding that default. But the WYSIWYG, the body field, that's getting the default design from base. And layout rules, like every single individual layout, gets its own file. And it's not even per page. It's like I'll have an L-header, for example, that's the layout for the header and how it sort of modifies itself as it goes across larger and larger screen sizes. And all of that is encapsulated inside that file. I'll have a footer one. Like on story pages that are node story, I'll have a story layout that works with those, you know, the layouts, the panels layout that I use or whatever, right? And then finally where I'm just sort of importing all my components, just right there. It's really pretty simple. I realized that I talked really fast, which is good. Because one of the things that I didn't get to show you, and I haven't really shown anybody, is the automated style guide. So let me jump out of my slides real fast. This will be plenty of time for questions. But one of the really useful things that I did recently on a project, MSNBC.com, I implemented a style guide, an auto-generating style guide. And see if I can pull it up here. It's really hard to see all the buttons from this angle. Okay, window reopened and closed. There we go. So there's this thing called KSS, Neath Style, I think it's Neath Style Sheets. And it's a way that you can specify, you can basically write some comments inside your SAS files. And then you just run this tool and you say, okay, that's where my SAS files are. This is where my generate to CSS is. Now, run right now and generate me a style guide, a bunch of static HTML files based off of that input. And this is the one that I did, this is the only one that I've actually done because I just finished this project a couple of months ago. And in it, it just gives me an example of, what are the heading levels look like? And you can see it shows you the sort of example that I'm using and then the actual style right here. I mean this is a real style because it's pulling in the generate to CSS. So this is the same CSS file that we're using for our theme on the Drupal site. So these aren't Drupal pages, but it's the same CSS. And the way that you specify that is actually really easy too. So this site was broken up a little differently inside of my base. There's actually several files there. So for heading one, I basically have this little code comment at the very beginning here. Can you guys see that? I don't need to make it bigger. So I specify, I'll scroll this way, it's a little higher. I specify that, you know, describe it so I can, this is heading one, I give it a sort of example markup. And then just specify what section of the style guide I want this to appear in. And because the comments are right next to the actual implementation, I would have to be really, really dumb not to update the docs when I update this style. Like if I have to modify this in some way that's relevant to the documentation, modify it, just do it all at once. And then just rerun the style guide generator tag, or the script. There's actually, I specify, there's a Ruby version of CSS which I could never get to work because it assumes way too much Ruby knowledge. But there's also a Node.js implementation of it, KSS Node. And that one actually worked when I tried it, which is, you know, very positive. So Node.js is what I actually used to generate these. And then go back over here. I can show you, so base, headings, you know, here's what links look like. Here's like an example section of text. Yeah, and then let's go over to our components. So, yeah, this one, this style guide I actually generated after the fact. And I came on to the project very late too. So it's sort of exposed some interesting bugs in our implementation. For example, this design component is applied with an ID selector, which I really hate. But I didn't know that until I generated the style guide. So I would like this to be a class logo instead of an ID. But this is the HTML that's required in order to get that design. That's not very interesting. There's a bunch of different styles, classes that are used for ads. Here's vertical styling on an ad. The dotted lines I actually added to the example markup just so you could see where the different pieces are. So you can modify the example to add in some inline styles to make it easier to visualize actually what's going on. Let's find, here's a better one. So here's our author names. This is the bylines on different stories. And when I want just this sort of default styling on author names, I just use the author dash names, design components class. And then there's a modified one with a border underneath it, author names dash dash border. Don't stress too much about exactly what you name these things. It's more important that you encapsulate the design than it is to name it. Here's another variation of it. This requires slightly different HTML syntax because it has this sort of partner logo next to it. Breadcrumbs. The great thing about implementing this automated generated style guide as you build the site is it really helps you to focus. What am I actually building? Have I really encapsulated this component well? It makes it much easier to create components if you've got an automated style guide that just runs as you're building stuff. But it's also really useful like this after the fact to sort of like, oh, let's see what's going on here. One of the things that I discovered when I did this was we had a SAS variable called, what was it? It was like, I think the name was like purple or something like that. And the actual color was green. And I didn't know that until I did the automated style guide. Anyway, if anybody has specific questions of how to do this, I'm around the next few days. And again, that was node KSS to do this. And let's go back to slides now. Actually, that's it. Thank you. If you have questions, there's a microphone somewhere. Is it right in the middle? Can people walk over there? I can't really see from this angle. Yeah, okay. You can. Good. Hi, John. Hello, Morton. I'm glad you didn't put any dirty pictures in your session, so I don't have to count on my next session. But that's actually not the question. You're showing the style guide. Is that a thing we should get into jubilee? Oh, yeah. So the classes, the naming of this stuff that I mentioned in SMACS, that we do have some documentation that really describes in detail exactly how this stuff works. And it was a group effort. A whole bunch of people worked on it within the mobile initiative for Drupal 8. And I don't remember the URL, but it's in the documentation. You can find it somewhere. I can tweet about it later, I guess. Thanks, I guess. I forgot my picture of you in one of these slides. Exactly. In a session in two hours, there's going to be a very good picture of John Albin paying his way through Drupal. Oh, are you doing this? You can make me pull it up now. Let's see here. And here we go. This is from the fugly selector hack. This is just for you, Morton. So this is one thing that I forgot to mention is that when you're using Drupal, sometimes it's really hard to put classes exactly where you want them. You may have noticed this problem. So I came up with the fugly selector hack, obligatory Morton reference. And basically the hack is a way to... Yeah, right. So sometimes there's a specific CSS selector that's really ugly that I have to use because Drupal, and I can't change the classes that I want to use. So I'm going to feature in the square title and then A, because I can't figure out how to insert a class into the link because it's like some render array inside this thing. So instead, I'll use the fugly selector, but then I will extend the beautiful sort of lovely design component class that I wish I could use. And for some reason this works really well because you've been thinking about all these design components as being independent, it doesn't matter that I accidentally increased the specificity of this particular selector because it's still very independent, right? No one else is going to use that same selector. You're not going to have any design component collisions going on. This is a great, great technique when you can't get into Drupal's internals to change the class that you really need. Just for your morning. Thank you. I was curious if you had any opinions on grouping classes within your CSS or within your markup, your HTML or template or whatever. I was reading, Harry Roberts is like grouping them with brackets around so you have like a series of BEM classes and you actually put like class equals and then brackets around related sets of classes. Just curious if you think about how you group them together for like readability and findability or any thoughts on that? That makes sense. I haven't thought about it, yeah. I haven't thought about that before at all, so you really caught me off guard. But the ideas behind design components are sort of independent of the actual selector you use as we discovered with the fugly selector, right? So, yeah, as long as you can work out a way, if you don't use the BEM syntax which is that double dash, double underscore and use some other syntax, find a naming convention that works for you and stick with it, right? I highly recommend the BEM syntax double dash, double underscore because it's easy, straightforward. It looks ugly at first, but it's really useful. How do you draw the line between what's a layout and what's a component? Right. So layouts really are about like big chunks of the page, right? Now, within a component you may have like be moving stuff around a little bit and it's fine to have a little bit of layout within your component like relative positioning or maybe even absolute positioning. But basically it's all relative to the other sort of loose collection of other HTML elements that are inside your design component, right? So a little bit of layout inside there is fine, but it's not about page layout where you're moving big chunks of the page. And basically if there's layout inside that design component, a little bit of layout within that design component, you should be needing that same layout every time you use that design component. And that's like you have variations where you tweak one of the positioning of one element, right? I have that sometimes. Well, I'll make a modifier that tweaks the layout a little bit. But you wouldn't have say the page as a component and that just has the page layout in it or the header as a component. Yeah, I mean I guess you could think about the page as a component and then all the layouts are just part of that, but yeah. And why not use sub-directories within components in order to sort of chunk up the long list of files? Is there a reason for that? So if you start doing sub-directories inside your components to like group them logically together, you lose the findability a little bit because you're like somebody's new comes into the project and they're like, okay, I just inspected the DOM, I find that name, so I'm looking for that file and now I have to look in like seven or eight different sub-folders in order to find that file name. I mean if you have some like development tools, obviously like a bunch of them you can just sort of type the name and it'll find the file wherever it is in the system for you. I'm not opposed to it, but it just, I don't really find it necessary. So let's say we're in the middle of a website development project right now and we want to move more towards the model that you've described. Any suggestions on taking what we have and translating it into what you've told us about? Yeah. So I've been on projects before where it's already been done once and we're just like tweaking it. You can transition your site if you're like halfway through to the design. You don't have to throw everything away and start over. It actually works out relatively well. It's like all the new stuff you try to use this model because they're highly independent. They're also independent of all the like awful ways that you did it, the first half of the project. So it usually works out okay, or relatively okay. So it's okay to do like half the site poorly and wait until you have time to kind of transition that into... Right, you can come back and refactor later and it'll be, you know... Yeah, I mean that's just the reality because if you could have unlimited time, well yeah, we'll just start over. No, that's not going to happen, right? But it's okay to switch the methodologies because they're highly independent so they're not going to have that big of an effect on the earlier stuff. It's more like the earlier stuff is going to have an effect on the later stuff. So you may find that there are specific rules that you have to refactor because they have two generic class at the very end of the selector and they're bleeding across into your design components that you build later. One thing that I should also say is that a particular HTML element could actually have a layout class on it and a design component that's okay. There's no reason why you can't have nested components as well. So like you have a design on the thing and then like inside the HTML there's another component that just happens to be smaller and fits within your other larger design components. That's okay, we're not specifying that they have to be next to each other, right? We just sort of want them to be independent of each other. No more questions? Thank you everybody.