 We're going to get started here. I want to welcome everybody. My name is Ivan Booth, and I'm the TripleCon front-end track chair. I'm a freelance developer at rootwork.org, and I'm thrilled today to introduce Jonathan Snook. Jonathan is most well-known for his book, Scalable and Modular Architecture for CSS, and if you're not sure what that's about, you're going to get to learn all about it in just a few minutes. While not technically a lumberjack himself, he's been smacking CSS under control for some years now. He's written for A List Apart, 24 Ways, and .NET Magazine, and also wrote two other books, The Art and Science of CSS, and Accelerated Dom Scripting. And he's actually speaking at both TripleCon and WebVisions here in Portland this week, so he's a busy guy. Jonathan has been building websites for nearly 20 years and currently works at Shopify. He previously worked at Yahoo, where his redesign of Yahoo Mail was the raw source of much of the smacks approach. I'm really happy to be welcoming Jonathan to TripleCon because Drupal8 itself is adopting a smacks approach for its style sheets. So while his ideas are applicable to any web project, I'm particularly excited to see the positive effect that it's having on Drupal front-end development. And while you can't get Jonathan Snook's face on a t-shirt, you can get Jack the Lumberjack. I can't see it in the back, but there he is. You can get Jack the Lumberjack on a t-shirt, along with the book itself, at smacss.com. So with that, please welcome Jonathan Snook. So thank you very much for having me. That was a great intro. I like that. So I'm here to talk about how your CSS is a mess, and to be honest, mine was too, and still is from time to time. So I came across this tweet a while back, and I think it's rather amusing. So observing that the maximum number of people who can productively, simultaneously work on CSS is one. How many of you agree? That's a pretty good crowd. And the thing is, like, you know, before Shopify, before Yahoo, I ran my own company called Sync.ca, and the thing with that is that it was only one person. That means that I was the one who had to do all the front end, all the back end, everything that I needed to do, deliver it off to the client, and then move on to the next project. That could have been the absolute best CSS, or the absolute worst. And the thing is, is that I wouldn't have known it, because I couldn't pass it off to the client. I never have to worry about it ever again. So, as I mentioned, right now I work for a company called Shopify. And at Shopify, we're a team of four designers. We work with five developers. But we're still only one team working on one project. That means we're all in the same room. And anytime I have a question, anytime I'm like, hey, I have to work on this file, can you just, like, not commit that? I've got some changes I need to go in. I don't want to deal with any merge conflicts. I can turn around and talk to people. But in between these two, I worked for a company called Yahoo. You guys might have heard of it. It's been in the news as of late. And I worked with a team of 30 designers. These guys were Photoshop kings and queens. They do Photoshop inside and out. And they would pass their work on to us, the prototyping team, which is the one that I worked on. Now, the thing is that we did prototyping a little bit different. I had this like brilliant idea that what if the prototypes we built were actually like production quality. And so we actually took the front-end code, all the HTML and CSS that we would do to build these prototypes, and we went off to a team of 200 engineers. That the stuff that we were producing ended up being integrated with multiple teams and multiple projects. So we were dealing with Yahoo Mail, Messenger, Calendar. All of this stuff was based off the same HTML and CSS. Because traditionally the way they did it was actually take a Photoshop comp, throw it over to the engineering team, and then six months later the team would go, here's the product, and the designers would go, that wasn't quite what I wanted. But when you're dealing with multiple teams, different teams have different ways of solving problems. And we really wanted to solve the problem once and distribute that. Really early on in the project, for example, we wanted to do this little autocomplete widget. So our team built the HTML and CSS and actually built the JavaScript prototype for this autocomplete widget. Passed it off to the different teams like, hey look, we've got this autocomplete widget, and then sure enough the Messenger team went away and they built all their own JavaScript stuff for it. And the Mail team went off and built all their JavaScript for it. And we kind of went, hey guys, we've already solved this problem. Let's just use all the same code. And this is something that happens with large teams working within their own silos. We really wanted to try to consolidate this. Now when it comes to CSS, I think that there's this conception or misconception that CSS is easy. I know in a lot of projects that I've done where, you know, with the back end development, all the PHP code, it's got to be code reviewed, you know, got to do that before it goes in. JavaScript, of course, got to do a code review. CSS. Oh, it's just CSS. Go ahead and commit it. Don't worry about it. And the thing is, it's like, okay, we take this site, that's just like plain HTML. We throw in some styles and just magically we have a site. You know, we have selectors. We have properties. And then suddenly we get CSS that kind of looks like this. This is copied and pasted from an actual project. And this is really just an abstraction away from inline styles because we know inline styles are bad, right? And this makes me kind of go like this. It's a little scary. Here's some code that I took from MySpace. You know, we have these really long selector chains. And if you can imagine the HTML that must exist for this to work, right? We have to have all these elements in place. They have to have all these classes on it. All these IDs. Everything has to be very meticulous or it's not going to work. And the thing is that the only thing that we really care about is the stuff at the end, right? We care about the status bar. We care about like the status thing. You can see there's probably a link in there. There's a separator. That's really all we care about. Now, Drupal doesn't get off the hook. This site I took from the Drupal.org website. And the interesting thing, I mean, I'm kind of shortening it here. But there's two things here. There's a header nav and there's a content nav. And they both do the same thing. It's a horizontal navigation. But instead of codifying this pattern and reusing the same code, they duplicated exactly this code for both things. And it's this idea of reuse that we wanted to take advantage of. I'm certainly not without blame. This is from my own website from a few years ago. I think this is my website hasn't changed in like four years. So I don't have to worry about it. The code can be, like I said, as good or as bad because I'm the only one touching it. And I haven't touched it really in four years. It's fantastic. This is great code. But really, this is what I cared about, right? I cared about what the author name looked like and I cared about what the comment number looked like. Now, of course, we often run into projects where, you know, we have a single CSS file and we just keep adding to it each new page that we work on. We add some more stuff. And, you know, you're working as a, you know, I just need to fix this really quickly. I'm just going to add it to the CSS file. And again, this is from an actual project. And the thing is, when we have CSS that is this big, right, we end up fiddling with it, constantly trying to change things, add a new selector, what we're going to throw bang important on it, we're going to get something that will finally work until, you know, maybe we just kind of get frustrated and get rid of it. Again, maybe some of you feel like this is, you know, you're really happy and CSS is fantastic. Okay, so, you know, I mentioned working at Yahoo and a lot of the stuff that we were doing. I started really thinking about the process that I was working on and I wanted to find something that was scalable, you know, for what we were working on and realizing that taking a modular approach, taking things into these little components and deciding on this architecture for CSS, and of course everybody loves acronym, so I called it SMACSS. And so the idea with this was, like, really trying to understand how do I build a website, how do I write my HTML, how do I write my CSS so that it makes sense. Now, there's a bunch of stuff in the book. I'm only going to talk about three things today. One is categorization. You know, how do we... What are the rules that we're writing? What are the purposes that they're serving Once we sort of categorize things, what is the naming convention that we want to use to help clarify the intent of what we're writing? And lastly, and this is going to sound a little weird, decoupling HTML from CSS. This idea that, you know, yes, CSS is designed to style HTML, but bear with me, we'll get to that. Okay, first thing, categorization. So in thinking about things, I realized that there was really sort of five categories that things kind of fit into. One are base styles, layout styles, module styles, state and theme. Just bear with me a little bit, because I realized that, you know, modules are kind of one of those things that you guys have a problem with. As far as naming convention, modules are a little confusing. So apologies that I wasn't as aware of that naming convention when I wrote the book. It's been explained to me that like regions and kind of like how you deal with templates is more the sense of things as opposed to using the word module. And then, you know, of course we have states. And then themes I know have a specific meaning within Drupal. And again, this is really just kind of talking about user-defined customizations. And again, I'll kind of get into that. So just think about that when I say module or when I say theme. I'm not talking about Drupal modules or Drupal themes, but really just sort of these other concepts which I'll get into. So what is the HTML element look like? No classes, no IDs. It's just what does that element look like by default? So if you're using a CSS reset, such as like Eric Meyers reset or something like normalization, normalize.css, those things are really defining what that baseline is for everything on the page. Those are your base styles. And then on top of that are your layout styles. So layout styles is, you know, you have a page and there's a lot of stuff in that page. What constitutes layout? To me, those are like one of the major containers, like you've got a header, you've got a sidebar, you've got a content area. And then you want to put content in here. This is just that structure that you have on the page. If we look at something like the PayPal website, you know, it's got a header. It's got this sort of main content area. It's got a little sidebar of stuff. You might have a grid system that you're using with on your particular site, something like 960GS. And again, it's just like, okay, here are these buckets of places on my page that I want to put content in. I'm not worried about the content that's actually going in there just yet. I just want to know about the structure. In Amazon, very much the same way. We've got a header. We've got a content area. We've got the sidebar. You know, we might have a little grid system on the side here. So now that we have that, we want to take these content pieces. Again, I call them modules. These are part of the naming convention. And we want to dump these pieces in. So we might have, like, tabs. We might have a customized list. We might have buttons. On the PayPal site, for example, we have the inputs. Very similar look and feel. You know, they've got a routed corner. They've got a little button. The gray background. All of these things, this is a visual design pattern that we want to repeat in a bunch of different places. We have our buttons. In this case, there was gray buttons or blue buttons. There's doing different things. But even these, like, little content pieces on the side here, where it's this repeating piece that is used over and over again. On Amazon, you know, where we have on the sidebar, this little thing with the image on the left, text on the right, all those different styles required to put that together, this piece is the module. This is the design that we want to reuse. And likewise here, you know, we have a different style. In this case, we've got the image on the top, different pieces of content that we're including, but it's a different visual style that we want to represent. So now that we have something, and we have sort of this visual style that is being represented for this particular module, we sometimes have variations on those styles that we want to demonstrate. So I mentioned with the PayPal site where they've got gray buttons and blue buttons. On Yahoo Mail, we had search buttons, small buttons, dark buttons. We had a lot of buttons. Each of these variations was a sub-module. Now, the thing is that sometimes it can be a little bit hard to recognize these differentiations. So for example, on Shopify, we were building the website, we had these little drop-downs. Let's see if we have a little pointer here. You can see that drop-down that we had. Click on a button. We've got this drop-down. It's got a little drop shadow, little rounded corners. It's got blue links, white background. And the thing is that when we were building this autocomplete widget, the designer originally putting this together was like, you know what, this is a search component. I've got my search input box, and I've got my search drop-down, and I'm going to style all of these using the classes to put this piece together. What you'll notice here, it's in thinking that way, it's thinking about the context that all this stuff is existing in, and it doesn't actually lead to reuse. When we look at this drop-down, it is actually quite similar to what we had before. It's got the drop shadow, it's got the blue links. The only thing is that we've augmented it with a couple other things, such as the little icon next to it and a little footer at the bottom. But other than that, it was actually essentially the same thing. So there was a lot of reuse in this, and it's about recognizing those visual patterns that we're trying to codify. Now, in the context of sort of modules and submodules, I refer to sort of like this root element that we have in the node. I refer to a node in our HTML, but a lot of modules have other components that are part of them, and I refer to these components as subcomponents. So for example, you might have a modal dialogue where we've got a header, we've got a body, and we've got a footer, and if you were to look at the HTML for this, you can start to see some of the naming convention that I'll be talking about in a little bit, but we can see we've got a modal, and we've got a modal large here, the module and the submodule name, but we have these other pieces, such as the header, the body, and the footer, and inside those, we have other content, and the naming convention is indicating here that they're blogging to something else. So you may have modules inside of modules, and these subcomponents are part of a particular module. Again, we'll talk in the naming convention that these things are related, and that's the thing that we want to really clarify here. So we have modules, and we have submodules. We also have things called states, and states for me are representing JavaScript interaction, that when you have JavaScript coming in and applying a state to a particular object, that we want a way of representing that. And so for example, we might have a default state, and then we might have an active state, but when I click on it, what happens when I do that? I might have a default state, and then a disabled state. These states that I can add or move from a particular item. Okay, so we've covered four things so far, base, layout, module, state. Last one is the... Now, theming, I think, is a little bit of a confusing topic. I know since I've written the book, a lot of people have sort of talked to me about, like, when do you actually apply theming? Because for me, theming is not something that is necessary on a lot of projects. In fact, in the first draft, I said there was only four, and this one was kind of like this throwing topic. Most websites don't have these requirements, and what are those requirements that I'm referring to? So in this case, you know, we've got this, yeah, mail theme that is purple, yeah, who loves purple, but not everybody loves purple. Maybe you get stressed out by purple and get stressed out by mail, and you know what? You want something a little bit more relaxing. Grass, blue sky, just relax. And it's this ability for the user to come in and customize things that we want to isolate those styles for them. And the reason is because if you can imagine the user coming in and like, okay, I want to preview what my theme looks like, do you want to have to take all of your CSS and send it down the pipe again, or would you rather just send the parts that are changing? And in this case, we just wanted to send the parts that were changing. We were able to actually change the theme using six colors and a background image, and that actually allowed us to create a ton of themes really quickly, but it also from a CSS perspective allowed us to isolate those styles really easily. And that was great. We also have other things like language where typography might need to be bigger. And it's these user-selected, user configurations that we are trying to isolate, and that's what I refer to as theming. Not every project has that. Most of the projects I've worked on do not actually need to use theming on a particular site. So with all this categorization, what does this really mean? It's about having your CSS and your HTML do one thing and one thing only. A gentleman by the name of Harry Roberts had written an article. You can check it out at snk.ms-1r. If you're wondering what the snk.ms stands for, it stands for snookums. But this article is interesting in that he takes this concept and applies it to CSS. And what you're writing, that the HTML, this node that you have on your page, is serving a single purpose. And the CSS that you're writing also serves a single purpose. Because what happens is that once we create all these dependencies, things become very brittle. I'm sure a lot of you have experience with this coming into a project weeks, months later. And then it's like, you know, this is one little thing. You find out the class and the selector that you need to change. You go into your CSS, you make your modification, and then suddenly four other things break. And of course we do all these other things. And then instead, what do we do? We just like, okay, I'm going to throw back important onto this one little case or something to get around that. And really, so here's an example. You can imagine a grid system where you've got your grid class being applied to the outside, you've got these columns, and you have this module. Maybe this is a playlist. And in this case, from a CSS perspective, you can kind of see something like this that might happen where I've got grids, I've got my column classes, and I've got my module classes separate. I think this is the moment we start combining these onto a single element. We start creating these situations where styles can clash. In this particular case, when I have these two things. And then we start adding, you know, well, in this case, maybe when I have a module class and a call class together, I'll do .call.module and I'll add that CSS there to override the other ones. And it's these types of things that we want to avoid. And this is a really simple problem to solve. We just create a new element that will be our module. Now, here's a less subtle one where we have a grid. But in this case, I don't have a column class. So it looks like, okay, I'm just going to apply the module class to this list item. And this makes sense to me. But the thing is, is that list item is still serving a particular purpose in the context of this unordered list. If we look at this CSS, very similar to what we had before, where the list item is serving the purpose of that column. And again, in this case, separated out. So this is a very, you know, doing back-end development like Drupal. You know, it's easier when we can isolate things. So if we have a grid system that I can create this grid system that I can reuse over and over again, no matter the context, the other thing is that I can test this. I no longer have to load the entire website, go through every single page to make sure that nothing is broke. I can take a look at just this HTML structure for this. I don't have to load in any of my module CSS or anything else. I just have to load in my grid CSS to see how that renders. Now, the other thing is that with the list item, if we look at this kind of thing where I've got a class on a list item, I can't test that list item by myself because the list item needs to be part of an unordered list or an ordered list. The LI itself as an HTML element just isn't really designed to stand alone. Modules and the root of a module be an element that can exist. For me, it's like it's going to be a div or maybe it's a section or maybe it's an article, whatever HTML element that you're using that it represents this root node that encapsulates that module into itself because the idea behind categorization is that it's about isolation and by isolating these things, it allows us to reuse these components in different contexts without having to worry about the context that it's in. Okay, so we've covered that topic. Name a convention. So with name a convention, we're talking about clarifying our intent because usually when we write CSS and create these long selector chains, we're worried about what does this HTML element look like on my page and it's this idea of thinking about the page that can cause some havoc because I'm going to touch on one topic before anything else, and I'm going to talk about the idea behind a convention too deeply is the idea of using classes over IDs. Now, if you remember way back to that Drupal slide using the ID, like pound, av head, the reason why I try to avoid this is if we kind of look at our specificity chart where we have these sort of four classes, this is where specificity, when I create a CSS selector, what wins? At the one end I have element selectors, at the other end I have inline and in between I have class and ID. Well, element selectors of themselves aren't going to give us a whole lot of what we want. You know, they're great at setting the base, but we need something a little bit more useful. You know, if we need something to reuse components over and over again, we're going to need something more than just an element selector. But on the other end, of course, we want to avoid inline styles because this is not very maintainable. So we're left with class and ID and at the moment you add an ID selector, the only way that we can override that is either by throwing important on it or having an ID selector with another ID selector with a class selector. We start having to add more selectors in order to get it to win. So we're going to take a look at a really quick example of that. So we have a link. We've got some dude links. And in this case, if you can imagine a form and on this form and you think, you know what, I'm only going to have one cancel link on a page. So it's going to be an ID. This is what I want to use. So my links are blue. My subdued links are gray. I want them to kind of fade into the text. And my cancel links are red. I really want to draw attention to these. So again, looking at the HTML for this, we have our links. We've got our subdued links. We've got our cancel links. But the client comes back and says, this is not going to work. But specificity says this is not going to work. Now I'm sure on a Monday you might want to take the time to figure this out. But yeah, on Friday we're just going to bang important all the things. And you know what? I'm done. I'm going home. But you know, this little specificity buster, we want to kind of avoid that. So what other ways could we have solved this problem? Well, I could have doubled up my selectors. Again, this would have worked. But of course all these other edge cases would be more and more examples my CSS gets bigger and bigger. And this is really easy to solve. We just make the cancel a class. And as a result of this we just apply that class to the element. And our CSS is simple. It's understated. Very straightforward. We can understand what's going on. Our HTML may still have an ID in there. That's absolutely okay. Our JavaScript may require that ID to be there. That's absolutely okay. But from a CSS perspective all we care about is what is this thing supposed to look like? And this is where I feel that classes are best suited. Okay. So now that we know that we want to stick with classes what kind of naming convention do we want to use? So for me a module name doesn't have any hyphenation. This represents the root node of this module. So what does this thing look like by default? So I might have a button. And then those submodules are in large button, small default search. So all these different buttons that we have. Now a common question that I often get asked here is like why are you prefixing everything when you could just do .btn.large? That would work just fine. The thing is that have you ever run into a project where you're like okay, I need you to find every single large button on the site. So you do a search for large. You do find any large buttons but you also found large inputs. You found large modal dialogues. All these different other contexts where you're using the same class name to do different things. And then you're like okay, maybe I can hope that everybody did .btn.large instead of maybe large space button or they did button space other class space large. You run into these situations where you have to create these weird regex expressions to try to find every single instance that you can do. It's also how many people here use the CSS preprocessor? Sass or less? Good crowd. So you guys know about nesting where you can nest selectors inside of other selectors. And then you kind of get into these weird things where the thing you're looking at, this .large class, is actually nested inside of a button selector but that's like a page up. And you can imagine doing maybe a git commit .large and you see like a couple lines before and a couple lines after. What does this mean? .large. I don't understand the context. So you have to click through on the file and you have to drill in. And it's just a lot more work to understand how these things relate. And this is why the prefix really matters. It helps clarify our context, clarify our intent in different contexts. Whether it's in the CSS, whether it's in the HTML, whether it's in a pull request, it just makes it a lot clearer for everybody working on a project. Now with states, when we're applying JavaScript on and off, and for me, I try to avoid ever applying inline CSS with JavaScript. I know as a JavaScript developer it might seem really quick and easy just to do if you're using jQuery.css. The moment you see that, you double think. Because anytime you need to update that, you need to go back to the JavaScript. If you're working together in one place, it makes things a lot easier to do. JavaScript should only have to come in and just apply a class and remove a class. So for example, if I want to hide something or show something from the page, I will actually avoid using the hide and show classes, or the hide and show methods of jQuery, and instead just do add class or remove class for hide and show and let my CSS take care of that. And what that means is that I have a lot more flexibility. I might want to look at maybe adding CSS animations so that when I go to show something on the page, it fades in. I can do these neat transitions and things like that that CSS are giving us the power to do now by using just applying classes as opposed to trying to use JavaScript to handle a lot of forming. And then theming, you know, using a theme prefix or for text might have a text prefix. So from a naming convention perspective, there are essentially three things. We've got modules, submodules, and subcomponents. And within SMACS, when I wrote it, it was like, we have module names that don't have any hyphenation. And that, to me, I can instantly know that's a root node. Now, if I'm looking at my HTML and I see a module name and right beside it is a module name hyphen, something else, I know that's a submodule. But again, no hyphens in the actual submodule name. The hyphen separates and allows me to identify a submodule from a module. And then for subcomponents, so if I see an HTML element that doesn't have a class name with a hyphen in it, or without a hyphen in it, then I recognize, okay, this is a subcomponent. Now, there are other naming conventions in there. My understanding is that the naming convention that a lot of the stuff that work is being done on AAA is taking this kind of approach, which is very similar to BEM, which stands for Block Element Modifier, which is another approach very similar to this. The idea of modularizing our approach to CSS and HTML. And in this case, yeah, they allow for hyphens in root nodes. So to separate modules from submodules, they use double hyphens and subcomponents use underscores. To me, this is a lot of visual noise. I've seen another technique recently that I kind of like as well, in which case it uses a single hyphen and double hyphen, and then for multiple words, this is a camel case. But the point is, is that when it comes to naming convention, the idea is to pick a system that works for you and your team and to be consistent. And consider the fact that you do have these three different kinds of nodes in your page. You know that you've got this root node. We have these submodules and we have these subcomponents. So whatever naming convention you decide to use, pick something, be consistent, and you're happy. Okay, so I've covered two things so far. Categorization, naming convention. Last one, decoupling CSS from HTML. So like I said, I know this concept kind of sounds really weird because CSS is designed to style HTML. Somebody used this really quick example. I think you guys can already imagine what the HTML for this looks like. We've got a nav, we've got a navli, and we've got a navli, right? But this is a horizontal nav navigation. Perfect. Of course, the client comes back and says, you know what, I really don't like the fact that customers have to click on products to get to a list of stuff. Can I have someone move their mouse over and get this little drop down that appears? Okay, no problem. We're going to just add this list inside. Great. And we end up with, well, you know what, those list items inside list items need to look a little bit different. So we're going to go ahead and do what we want. And the thing is that we have to start writing more CSS to override the CSS that we wrote before. You know, list items by default don't have any float. We floated them and now I have to remove the float. You know, any of the padding or background colors that I had on the regular nav, I now have to remove those or overwrite those in order to get everything working on the links inside the drop down. So, how many of you still have to worry about IE6? Oh, there's... Those are slow hands, sad hands having to put it on. I'm sorry. Well, for the rest of you, childselectors are awesome. And the reason for that is because it limits the scope, right? We're now decoupling where before this nav li was applying to everything deep within it. By using this childselector, we're just saying we're just applying to this one particular thing. So now we're no longer impacting all these other elements. This is what I mean by decoupling HTML from CSS. And the thing is that now these styles aren't affecting this drop down menu, and I can style that drop down menu as its own thing. So I'm going to apply a class to it to identify that this is a different visual element. You know, this horizontal nav is completely different from this drop down. Yeah, they're both navigation as a construct. But from a visual perspective, they are completely different, and we want to style those different. So giving it its own class and then using the childselector to limit the impact. So that if I wanted to put another menu that had a different visual style than this one, I could do that. I could know that when I do that, when I put this module inside a module, it's not going to be impacted by the styles that I've created here. So we've got this box. And in this box, you know, I've got a list of sites that I like. And I think, you know, I've only got this one box, this HTML. Very simple. I've got a heading, and I've got an unordered list. So I'm just going to be really simple with this. I'm going to do .box. H2.box, you will. Simple. Of course, the client comes back and says, wow, that one box looks fantastic. Can I get some more boxes? And he talks about what the company is, and you know what, we actually have a sponsor. So if we can get, like, a little sponsor image to go in there as well. And what you can start to see is that the HTML structure here inside this is getting a little bit more unpredictable. So we can do the quick fix and just start adding more selectors here. OK, .box.p, we're going to do this. .box.p, we're going to do this. And we're going to get closer to what we want. So in this unpredictable scenario here where we don't know really what the HTML could be, we want to make it more dependable by creating a class and applying that. So that .box body. So again, the .box with the hyphen in front of it, this is indicating that it is related to .box. They're all part of the same module. And we have this sub component that we're going to style in a certain way. And then we can apply that class to those other elements. So it's about applying a class when the HTML can't or won't be predictable. So now I'm just going to go back to this here to explain another way that we could possibly solve this. Again, if the HTML can't be predictable, let's make it predictable. And the way I would probably end up solving this is actually adding a div and surrounding each of these pieces of content with a div. So then my HTML becomes very predictable where I have a div on the outside and then I've got a heading and I've got a body. And that body is always going to be consistent. The content in there, I don't care about. It can be something completely unrelated. But then I have this predictability. So when we have predictability, we can rely on element selectors with our module selectors, or if it won't be predictable that we want to apply classes to give us that predictability. Okay, so what does this all mean? It's the idea of shifting and sort of thinking. Because I think traditionally, I've seen this in a lot of places and certainly the way I used to approach things was this idea of coding CSS for the page. You can imagine a site that had an inside template and a home template. It was a very common pattern. Tons of sites have them. Thousands, hundreds of thousands of sites have them. And the thing is that we need to shift our thinking so that we're thinking more and more about what we need to do. It's actually a really great article that came out recently from Dave Rupert called Responsive Deliverables. Definitely do a Google search for that. And in it, he talks about Paravels had worked on a site for Microsoft and how they were really... Okay, what are these components and these parts of the page that we needed to use in different contexts? Because once we start looking at responsive web design, you can start to understand that in different contexts we need to take something on the page and represent it in a different way. And this is something that I refer to as state-based design in the sense that you have all these different components on your page and you need to represent them in different ways. So, for example, you might have a layout or module style, so this is like, okay, one particular state. Our submodules represent a second state. You know, we have these states or the state categories that I had described before where we want to add this JavaScript on and off. We have pseudo-class states, things like hover, active, focus. HTML5, there's a CSS3 module called the UI module that adds a bunch of other selectors like in-range and out-of-range. So if you use a number field with max and min, then you can actually use CSS to style that. And we have all these other classes that are not coming in that allow us to handle some interactivity completely at the CSS level. And then we've also got media query states. The moment, you know, a browser is resized to a specific width or maybe we're looking at on a phone or on a tablet, in these particular states, how do we represent the things on our page? What does our layout look like? What does a particular module look like? Now, I love this. This thing called CSS Panic. This is pretty incredible. So we've got these little alligators that you click on and when you click on them, this little counter goes up, this little timer at the bottom. The thing that really impresses me about this is that this is done completely with CSS. There is not one line of JavaScript for that. If you dig into the code for this, there's these enemies. So we have this object on our page, that represents these enemies. Now, the interesting thing here is that if you kind of notice this appearance property, they've changed it to a button. And the reason for that is because those alligators are actually checkboxes. Now, checkboxes are notoriously difficult to style. And so they use a lovely browser feature to allow them to style them as if they were buttons, which give you a lot more control and allow them to style them to look like alligators. And then with that, they were able to adjust like, for example, pointer events so that when you try to click on it, it doesn't respond to mouse events. All the animations are removed. The opacity is removed. So it disappears from the canvas. The moment you click on that checkbox, it disappears from the page. And this is what I feel like as an industry is something that we're moving towards. It's an idea of being able to represent things in different states. So this alligator is, default state is moving in and out, using CSS animation to move in and out. And I mean, like, when CSS animations first came on to the scene, I actually wrote a blog post and I'm like, no, this does not belong in CSS. JavaScript, this is behavior. But again, this mental shift of thinking of things as states, you realize, okay, well, you know what, yeah, this kind of makes sense. And then, like older versions of OSX had, you know, the moment we have this dialogue, what does it look like when we shift between states? And realizing that CSS is actually a great way to describe these things. And as a result of that, it's okay, you know what, yeah, CSS animations make a lot of sense. So, you know, if we have an alligator on our page and, you know, who doesn't these days, that we can say, okay, what does it look like this? And then when we change its state, it should do something else. You know, with the navigation, the moment we move our mouse over, what does that look like in a different state? When we resize our page, what does it look like in a different state? Okay, so I've talked about three things. Categorization, naming convention, and decoupling HTML from CSS. Thank you very much. Now, we do have some time for questions. So there is a stand right in the middle. We've got one person all set to go. Thank you. This is really fantastic. One thing that you didn't cover, and I wonder if maybe you didn't cover because, as I suspect, it's not that important. I used to spend a lot of time sort of obsessing over, like, categorizing, like, where to put things in my CSS file. And as I started to just get and really, like, embrace the sort of firebug tips of situations where it kind of does matter and what to do. So in this case, yeah, there's a whole thing about, like, file organization and, like, how you structure your files. I probably could have stood up here for another hour and talked about that. In that particular case, some of it is minimized. You know, when you start isolating styles so they really stand alone, yeah, you can have them all in one big file. And as long as you know where each section is, where each module is, that, you know, when we start looking at preprocessors and we start looking at, you know, how do we bundle things up? The ability to isolate things away into their own files give us a lot of control. So we could say, here's a file for this module. Here's a file for that module. Here's a file for this set of layouts. Here's our base file. And so you end up with 40, 50 different CSS files that really construct the visual design of your project. So, you know, here are the components. Here are the different visual patterns. And here are the CSS components for that. And when I talked about isolation early in the presentation, this ability to isolate things says to me, okay, what does a button look like? I can take just the button HTML, just the button CSS, load it up by itself and go, that's what I wanted. And if I need to make any changes, then I can take a look at just my buttons and know exactly how that's going to render. You know, okay, I changed my modal CSS. I have to click on every single modal dialog and make sure nothing broke. That's not something that I want to do. I want to be able to just isolate those files and be able to test that. So from a file perspective, yeah, a lot of the naming convention does minimize that, but breaking things out I think also gives us a lot of benefits as well. So a couple of questions. Well, first of all, thank you for inviting this. It's kind of, it made it possible for us to try to make, again, developers understand the complexity of CSS. It's not you making CSS, oh, you're making the bottom green. Now, so the thing is, we're trying to move a lot of these principles into a Drupal 8 and into a Drupal core. And one of the issues we, of course, came into was modules, that naming thing. So I'm wondering how much we're going to have to bribe you to get it to be called components instead. That was what I thought. I mean, this, I guess it's just... I need to create a new book, the Drupal edition, and just a renamed one. That was actually just, it's kind of the issues we're going to have now that we have modules and SMACs modules, and we're going to have blocks and we're going to have trick blocks, and we're, oh, god damn it. Can the world just understand our problems and align? We're big enough for that now, right? I mean, we have 3,300 people. Well, thanks, Roy. One of the things that makes me feel saddest is that I can have a lot leaner markup. I can just include and extend a lot of classes in my CSS. A lot of what SMACs does is it seems like it's being extremely, you know, kind of prolific with its classes in order to make sure that everything will be consistent and targetable and reusable. So when you're using, you know, I can see this and say, okay, like, writing CSS, SMACs makes a little sense, do you really use a lot of heavy including and extending or do you just try to keep it more? Yeah, so when it comes to preprocessors, I use things very judiciously. I don't do a lot of extend. Specifically, I don't extend across modules. So I will extend within a given module. So that may allow me to minimize the amount of classes that I apply to a particular element. So, you know, with the example where I have a module and a sub-module class on the same thing, then I can compact that into a single class. With that said, there are caveats to that. So there are situations I tend to avoid that. So choose my words very carefully. When it comes to a lot of preprocessors, the thing that I'm worried about is not only the HTML size, but also the CSS side. And a lot of the things that I've seen people do end up with really large files. Especially if you have complex modules with a lot of sub-components. The moment you go to extend that, it starts to balloon your CSS file really quickly. And I feel that by applying these classes to the HTML that it is still possible to do it judiciously. I don't I will not have an HTML element on my page where I've got it. I keep it up. Usually two on occasion three. The moment I've gone beyond that, I need to rethink how I do things. And that is an approach that has worked well for me. So I use SAS. We use SAS at Shopify. I like it. The mix-ins. There's a lot of the mix-ins that are fantastic. But a lot of the stuff that extends is not something that placeholder is something that I think you need to reuse in a lot of places that you want to sort of codify as this object. I will tend to use placeholder. It still results in some duplication. And again, when you start seeing too much duplication then the question is, am I looking at a visual pattern that is the same and that I really should be codifying as its own object? And I think a lot of this argument actually comes out of this debate of semantics. So a lot of people, instead of having a module that is like, here is my list view. We'll say, no, this isn't a list view. This is a list of products. So call this products. Call this one events. Call this customers. And use extend to say my products look like, my events look like, you know, all these different things. And all that does is it says your CSS is not just .products, it's .products, .events, .and then you end up with these long selectors. And this really, to me, is harder to maintain code. You know, going into the CSS inspector, going to examine something, and suddenly you just see this block of selectors and you have to think, oh, okay, that's I guess what I want. And that for me is harder to maintain, whereas if I can stick to just one or two class names, it's a lot easier to look and say, okay, this visual pattern is a list view, and then I'm just going to reuse that list view class in all these different contexts, as opposed to worrying too much about what the actual content is. Okay, thank you. Thanks. I come from SUNY JNSAO. I have a question about the responsive site. We are working on this project for our website. My question is, do we need to rewrite all the CSS code? No. Yeah, I mean, when it comes to responsive web design, again, where we're talking about, okay, what is changing in different contexts? And the context shouldn't be phone or tablet. So, in other words, you may have this three column layout that when we move down to a particular size, the content just doesn't fit in there anymore. And so you may think, okay, the modules that are existing in here, do I need to change those, or do I need to change the layout? And then you should be saying, okay, in this particular context, now I want to change to a two column layout, now I want to change to a one column layout. So all we're doing is we're creating these styles that are affecting just the layout in just these one or two different cases. It may be a case where, you know, maybe it is the module that needs to change, that once it gets to a certain size, then instead of having image to the left text to the right, that we now stack image on top text to the bottom in order to get everything to still work within, you know, the three column layout that we have on a tablet. And so once we start looking at, you know, how do we, how does our page work? And from a design perspective, what happens when we do that? Now, admittedly CSS right now is still limited in the sense that what you care about that module is like, how much width does that actual module have in the context of the layout? And response to web design right now is still all about the page. What does that module look like at the entire page? And that's still difficult for us to solve. So we always have to say, okay, this module, one at resize, I'm going to change the width of this, or I'm going to do something different with it in this particular context. But where this breaks is that if I say, I might go and actually change my layout now, it's going to affect all these modules. And therefore, when I resize down, I now need to go back to change my modules because I changed the layout in this particular context. So that is still a problem with CSS that just CSS as a spec hasn't solved for us yet. Hopefully in two to four years, it'll be solved. Thank you. Previous question. How do you handle elements, especially when using preprocessors to help our classes like clear fix and image replacement? Do you extend to include? So for image replacement, so in the case of preprocessor, I tend to have a helper of CSS file, and there's not a ton of stuff that I put in there. So when it comes to image replacement, I'm almost always now, I have an icon module and so in the book, actually, I have a chapter on the icon module and I feel like it's a really useful pattern. I learned it from a co-worker at Yahoo and I was like, this is brilliant because it made things a lot easier. And the so that to me, image replacement is a module. Clear fix is something that I'm going to apply. Now with that, when it comes to float containment, like so, why am I using a clear fix? I'm almost always using a clear fix because of float containment, because I want a background image to appear. So first, do I even need to use one? In a lot of cases, I don't. Just having the next module underneath it, maybe I just say clear float, clear both and boom, I've solved my problem. Or I'll actually use position sorry, not position. Overflow hidden as my float containment. So on this particular module, because I know I need to update floats, I'm just going to apply overflow hidden in that particular module as opposed to applying a clear fix. So again, it's like I'm thinking about this module. How does that module behave? Applying the classes and styles that I need. Using like the actual clear fix where you've got like the after and those types of things are things I try to avoid and very rarely do I actually need on a particular project. So when I do need it, I'm just going to apply that clear fix in that one particular case. But with a lot of the projects that I've worked on, those helper classes I've tended to not have very many. Inness of either the CSS or those markup like for a grid system. You know, I'd rather have like section, it's like a class of main content and then a side, just sidebar first. And then include you know, three in the sidebar. I wouldn't want to have classes in there especially like that. And that's one of the main advantages of SAAS is you can actually have semantic markup in a grid system and you're not locking yourself out of that kind of CSS and garden ideal. So, you know, a lot of things like button. I think those can be explicit cases where it makes sense to mark that out. But there's other times where, let's say at a break point or a state change descriptive. So I mean, would you still be like this is a common joke. That really sucks. Thank you for laughing. Naming things are hard, right? Because we often will gravitate towards a particular naming convention and when it comes to things like responsive web design, I'm not going to apply a class as .tablet so that I can actually use that in order to style that. I avoid that. I avoid saying this is a nine column layout. I'm going to say this is a grid layout and I tend to keep, with a lot of the design work that I do, I keep my grid systems very simple. In other words I don't have a 12 column grid. I've got a three column grid where I've got a four column grid and that's pretty much the extent of it. I'm not going to say well, on this particular page I'm going to have two columns on this particular thing. I'm going to have three then I'm going to have four, then I'm going to have eight that I'm just going to mix all over the place. I tend to keep my layouts pretty simple. But that's my design approach. But with that the naming convention that I'm going to use I'm going to try to name things in such a way that I know that that class is still applicable in all the different contexts that it exists in. And that's the thing with a lot of the other naming convention that I talk about. And it's interesting because I still run into this problem, I still fail at this when it comes to naming things. On the SMACS website when I first put together the workshops page I had this area where each of the locations that I was having I wanted this blue highlight. So I'm like, these are location modules. This is the style that I want to use. And then when I created the store I'm like, you know what, I'd like to highlight these things and it's going to look exactly like these locations and so I added a location class to my products and I went, ooh, that's not good. But as a lazy developer that's what I did. And so what I should have done is really thought about what was the design goal that this thing was serving. Yes it was a location, but the design the purpose of it was to highlight something on the page. Calling it highlight would have made a heck of a lot more sense and if I want to highlight a product or highlight a location it would have worked perfectly in both of those contexts. And that's where naming convention and it's something that is a constant thing that as a team you have to work on to make sure that everything is consistent and makes sense and that you know that in all the different contexts it's going to make a lot of sense. And on that, thank you very much. Thanks for sticking around.