 How are you guys doing today? Good so far? Good day? Yeah? Just out of curiosity, who here writes CSS as part of their day job? OK, good majority of the room. And how many of you guys saw Jake's talk earlier today? OK, this talk's going to be pretty similar to his. And he did an excellent job. So I'm going to echo a lot of what he said. So are you here, Jake? Good job, man. Yeah. So very briefly, I'm Shay Howe. I'm a designer, front-end developer, and teacher at the Star League. I'm from Chicago. I help organize a handful of different meet-ups and things there. If anyone ever comes to Chicago, look me up. I'll take you guys out for a beer. Introduce you to the community. If you have any questions about anything I talk about today, feel free to reach out to me at shayhow.com or shayhow on Twitter. I do have these slides online, and I'll give you the link at the end. So don't feel like you need to scramble to write everything down as I work through this stuff. So some days, when I get to work and I jump in a code base, I feel like I'm the captain of this ship. I feel like it's chaos. What I'm doing is extremely fragile. And I'm fighting a storm. I'm just going downhill. And I might have came into this code base to make the smallest change, but the ship is just taking on water. Does anyone share that feeling? You have the best intentions, and you're like, I have to change the background. Or I'm going to fix a typo, and you do that, and just trouble arises out of nowhere. So why is that? What are some of these common problems that cause this to happen? I think generally speaking, websites don't scale well. They become bloated. They're brittle and really complex as the days go on. At times, we're working with spaghetti when we need Legos. We want to snap these things together. They should be modular. We can plug and play as we go. But instead, we have just soggy noodles. We have to mush in one direction. And our efficiency diminishes, right? Not only as an individual, but as a team, and as a company. And our website can take on this cruft. So what's wrong? We have these perceived best practices. And I don't think they're quite best practices anymore. We've had these best practices for so long, and they've been treated as rules to never be broken. I think you guys, I don't think anyone in this room has ever broken a rule. I can see it in your eyes, you're a good crowd. But our technology and languages have changed, and so must our standards, and they haven't yet. A lot of these rules exist around separating our presentation from our content, and that includes the ability to sort of avoid adding extra elements or classes into your markup and to really leverage selectors. And to dry up your markup, remove any styles you have. We understand that HTML is for content, and CSS is for presentation, and that is great. We should stick to that. But these rules are a bit ambiguous, and often taken too literal and quite too far. I can get behind the idea of removing tags that symbolize styles, such as font and big. But when we start talking about removing classes and trying to avoid them, I think we have to slow down and have a conversation about that. We start to write styles that look a bit like this. This is actually a really bad attempt at separating our presentation from our content. We do things like this. Our styles are so tightly bound to the document, it prohibits any change. We did the exact opposite of what we set out to do. We're trying to keep our styles separate from our markup, but I can't move that button out of that feature element without breaking it. I'm stuck changing not only my CSS, but my HTML. These long selectors start to drive up the specificity of our CSS, and they're not modular, and they start to harm performance. I mentioned specificity, so to clarify that, specificity identifies how styles are applied to an element, right? And every selector within our CSS has a specificity weight. Now, the higher specificity will trump the lower, but the key is here to keep our specificity as low as possible, right? And that's what's gonna create the most efficient code. I'll talk a bit about this in a little bit. But my goal is just to go to work and feel like this, like the captain of a fleet of ships that are all heading in the right direction, right? A team that has a North Star, and we know how to get to that Star, right? But what is that baseline? What's that tactical HTML and CSS we can work towards? We believe it lives inside maintainability. And what is our code if it isn't maintainable, right? We can't scale, we can't fix bugs, we can't improve performance, can't really change anything. Even to change that background or that typo starts to cause a problem for us. Andy Hume said last year at South by Southwest that websites change, we have to optimize for change. And he has a genius, right? The only constant we're going to have as a website is change. So we have to focus on maintainability. And I sort of break it down into these three categories, organization, modularity, and performance. I'm going to speak to a little bit about each of these. I'll start with organization. I think you really can't do much until you get organized. And organization's going to help drive modularity and performance. So inside of that comes the approach. And we have to stop thinking about websites as just pages. We have to think inside of components, right? These are systems we're building. We need to take a visual inventory, identify those components and their abstractions, and build a library and work from that. I do it in this manner. And please feel free to do it however you want. This is what works for me. I think you and your team can find an approach that's different from this that works equally as well. I'm just going to sort of share what I've done. I organize my styles and do three main groups here. Base components and modules. And base would be sort of your core styles for your entire site. So maybe a normalize or reset file. Any sort of default elements such as typography, your font sizes and weights, right? A grid or any variables you might be using as well. Components then are sort of driven from design. The user interface and design patterns you might see. So alerts, buttons, lists, things of that nature. Modules then I see are things that are derived from business logic. So your header, your footer, things of that nature. Now, components can be shared and reused, right? You could take a component from my website and use it in yours. But it might not make sense to take one of my modules and use it in your website, right? You might not want to copy my header. It could get a little weird. Components can be reused inside your own website as necessary too, right? So they can be used individually or inside of these modules. It all depends. But what's important here is to watch for the unpredictable, right? And different styles and similar elements. If you have two buttons and one's just slightly bigger and maybe has a different rounded corner to it, think about combining those, right? Good design is consistent. Good code should be consistent too, right? My goal over time is to not write CSS, right? I want my instinct to jump in and just start writing HTML and see how my styles are inherited inside of that, right? And from there I can write CSS as needed, right? I don't want to do it the other way around. So to put this into perspective, I want to take a look at RDO and sort of see how I break out their styles. I see their base as their font sizes, weights, colors, the grid in which they're working from. Components then would be like a list such as their navigation, their buttons, any of the pagination stuff they have going on. Modules then live inside their head or footer, even that carousel they have. So how do we get to that modularity? We put a lot of attention into how our styles look, right? What's this background gonna be, right? Does it have a drop shadow or a border radius, things like that? We put a lot of effort into those properties and values. We don't put a ton of effort into our selectors. I think that's a mistake. We need to take a grid and build our foundation from that, right? And find a way to sort of keep our layout separate from our theme. I've heard a few people say this today and that excites me, I like that. You might see some code like this and at a glance it doesn't look too bad. Has anyone ever written code that looks like this? I know I certainly have, yeah? That's just me and you, Jake, what are you doing? That's a good one. That's good. But what's bad here is our layout is baked into the theme, right? That margin and width, those box model properties we can break out and put inside the grid. Something like this would be a lot better, right? These styles can now be reused. I've changed the class to a little bit better name and I can reuse that featured box on different elements throughout the site. I can also reuse that grid where necessary too, right? And I just assigned multiple classes to that one element. Now if you're using a preprocessor of sorts and you wanna sort of clean up your markup you can extend your grid inside of these elements. It allows you to sort of do this a little more strategically. We also have to think about our content and remove that parent container dependency we have, right? Let's just drop parent selectors all together and style elements regardless. So allow for better semantics. Something like this doesn't look bad to the eye, right? But that H2 is really tightly coupled to that box. And what if that H2 needs to change to an H4? Say the semantics of this page change as we add content to it. Now we're stuck editing our HTML and our CSS again. We better to do something like this, right? Where we don't couple those together. We use a different class. And this will adapt with semantics, right? And we can keep our page weight down and this will sort of grow and performance will be fine as well. Now, say we take that featured box we move it into an article of sorts. Maybe I want to change the background color of it. But this location-based selector isn't good here either, right? We're overwriting the default. We're giving the browser twice as much work, right? And we're coupling those styles to the parent. And what happens when that article needs to change to a section or a div, right? We fall into that same trap. We better if we did something like this. We created a new class branched from the original. We don't override any of the properties. And we keep these really modular. We can share them however we need to. Alert buttons are a culprit of this as well, right? We take all our alerts and put them into one block of styles. This doesn't allow for these to be reused at all, right? Enchanters are, I'm gonna have multiple types of alerts. There might be an error, a warning, a success, a notification of sorts. Be better if we did something like this. We broke these styles apart for reuse, right? Those shared styles can be abstracted, right? And shared amongst all the different alerts. Now we can have alert error, success, warning as need be, right? We'll take that border radius and padding because that's gonna be used on every alert. And then we change the background color and color of that text specific to the exact error message. Now as we do this, we have to keep an eye on specificity, right? And we can be explicit by using classes and classes outright. We have to understand a high specificity will break the cascade, we have to keep it low. If I have a selector high up in my style sheet that's extremely specific, right? Overly high specificity, it will overwrite anything that falls below it regardless. And then you fall in the trap of starting to slap IDs and bang important on things, right? And this gets ugly, right? So we have to keep that specificity low, try and avoid that stuff. And use, or minimize the use of nested selectors. If I go over above four selectors, I stop, I'm saying, you know what, maybe that could be better served as a class. We see something like this. It's way too many nested selectors here, right? The specificity is only going to continue to grow as I try and target elements inside of elements here. That specificity is going to grow. And over time I'm not gonna know which rules even take precedence over the other. I'm gonna get really confused and trapped. And if I ever see two IDs in a selector, I can really get bad for them, right? IDs are supposed to be specific. So why would I have two? Something like this might be a better approach. We use classes, we're really explicit here without raising the specificity. These can then be shared amongst other elements too, right? It's more efficient and it's also less work for the browser to hunt down the DOM and find all those elements. Now, how can we sort of keep an eye on specificity? We have this formula, excuse me. And it revolves around counting IDs, classes, pseudo classes, attributes, and elements inside of our selectors. Now, the high specificity we see here, if we count these out, right, there's two IDs, primary and main. So we put two on the board. We have two classes, gallery and media. So let's put two up for that. Then we have two elements, div and figure. And we compile these, we can read that as two, two, two. It's important not to read that as 222, okay? Now our low specificity, we just have one class. So that can be compiled as zero, one, zero. Now, these aren't a direct count, this is more or less a ballpark for you, right? You wanna try and keep these numbers as low. Think of this as golf, you will. 11 classes does not equal 110, right? This doesn't compile over. We all know that 11 classes will not override an ID, right? So we can't really compound that zero and look at that as 222. So inside of using classes, we need to use good names for our classes. Harry Roberts said it best that classes are either sensible or nonsensible, right? We're writing them for ourselves and for those that we work with. So let's make them developer-friendly. I should be able to read a class name and know exactly what element that's speaking to, right? We don't need to encode it and make it super short and hard to distinguish. We also don't wanna deeply nest these classes or combine them inside of one selector, right? That goal is to keep specificity as low as possible. So you might see something like this. And I don't know what PR and UN stand for. Does anyone wanna take a stab at what PR might mean? What's that? Puerto Rico. I'm doubting that, but what else? Print, is that what you said? Sorry. Press release. Okay, those are good guesses. These are really deeply nested, right? And what happens when I move UN outside of PR? What does that do? It's not gonna work. We have very limited portability inside of these, right? And these different levels of strength, having to continually nest these styles is going to continually grow our specificity. Now, PR doesn't stand for Puerto Rico or print or press release, it stands for price. But you would have never known that, right? It's a really hard thing to guess. So we need to come up with better naming, right? PR is shorter, but it's not explicit. It's not gonna tell you what that is offhand. We can also put these selectors on the same strength, right? There's no increased specificity inside of these. This is more modular, more performant for us. We might do something like this from time. We combine two selectors, right? But that increases the specificity of that selector, right? Can lower the efficiency of it. And large is kind of an ambiguous class name, right? If I'm using it on a button, chances are I might be using it on other things, such as pictures or headings and things like that. How do I know exactly what that class of large applies to over time? I can get lost. It'd be better to do something a bit like this, right? Just hyphenate it, make it button large. Use a better class name. We're the same strength. We decrease the specificity here, right? Again, we're doing this in the name of making more modular styles. Now what I'm saying isn't new, right? I'm not reinventing anything here. Nicole Sullivan outlines a bunch of this in her work with object-oriented CSS and some of the stuff she's done with Facebook and other companies. Jonathan Snook has also done the same thing with his work at Yahoo and other places where he has sort of created the scalable and modular architecture for CSS. These guys in Gal are raising awareness for this stuff much on a greater level than I am, right? They're advocating maintainability. So if anything I have said is interesting so far, you should really look into these because these guys are the pioneers of it. So performance, then. This sort of rounds off maintainability and brings it together organization modularity at once. We need to look to find ways to reuse our code and avoid duplication and stale rules, right? Find patterns. If I ever find myself copying and pasting CSS, I stop immediately. I should never have to do that, right? I should find a way to share that code, make it more modular. How can I do that? She'll also think about defer loading of some of our unused styles. Your homepage is the most popular page in your site. You likely don't want to load all the styles for all your subpages on there as well, right? Let a user hit your subpage and then load those styles for them. Don't give them one heavy payload all at once on their first initial visit. You only have one chance to make that first impression. This isn't good. This is a use of copying and pasting here, right? This is repetitive declarations. If I continue to do this, I'm just going to continue to add more bloat inside my code. Now if I'd extend those selectors with the comma, it's a little better. I wouldn't call it great. Not quite there. It would be better if I gave them a class in general and then just use that class inside my HTML, right? It's more modular. I can change those elements as need be and move them around. We also want to find ways to sort of minimize our request, right? We can do that by combining files. So we can take our CSS and put them all into one, all of our JavaScript into one file. We can find ways to reduce code weight as well. And how can we reduce HTTP request with sprites and data URIs as well? Is anyone using data URIs by chance? Yeah? Cool. So sprites, if anyone's not familiar, are a way to share a background image across multiple elements so that we don't have to make multiple requests to the server to download a background image. In this example, we use that class of icon to set a background image. And then we use other classes to position that background image on different elements. So we sort of have this whole and we sort of slide it around so that different parts of the background image are exposed as needed. Now, we shouldn't go overboard here, right? We should only common, or sprite common images. So think of those on a component level basis, right? If I have a header, I can just create a sprite with all the images inside of my header. Or if I have social media icons, I can create one image with all of those in it. I don't want to create one large sprite for my entire site. Because then it's likely that I'm loading more images than I'm actually using on the page. We start to defeat the purpose. Data URIs are a way to take that data that is actually the source of that image and include it inside your HTML and your CSS. This reduces an HTTP request altogether. And what is the fastest HTTP request you can make? The one you don't make. Exactly. So this works in both HTML and CSS, but we have to use these with a bit of caution too. So it's pretty difficult to edit, right? Every time we change that image, we'd have to go out and find its source and drop that back inside our code. That can be a pain. Now if you use Compass, there's a way that it will allow you to do this for you, which is pretty handy. But we also have to be careful. We have a really small image. Sometimes the file size of that image is actually smaller than its raw data. So by taking that data and just putting that in our code, that might be larger than the actual image itself. So we have to be careful about that. We also need to look to compress and cache our files, right? Let's harness GZIP compression and compress images without losing quality, right? And I'll talk a bit about that. And we have to find ways to reduce the response time on these files we're requesting from the server. Fortunately, the HTML5 boilerplate does an excellent job at this for us. It includes this default HD access file. And inside of it is GZIP compression, pre-baked in for us, as well as caching and setting some pre-determined expires headers for us. Unfortunately, this works on most Apache servers, right? It's in your server's best interest to basically cut down on the number of files you're serving up. So this stuff's fairly easy to get turned on. And the results are great. We can dramatically cut down our file size. So here you can see I take the HTML from 4.18 down to 165, right? It's over 60% that I'm cutting this down. CSS is in that same ballpark as well. We can do the same thing with images. It's a little difficult for you to tell here. But these images are compressed without actually losing quality inside these. So when I say without losing quality, I'm not saying that you're in Photoshop and you do Safer Web and you start to slide that number down. You're like 60% and the image starts to get a little pixelated. We don't have to do that. We can save for web, let it compress it. Then we can run it through another filter, right? And that filter will go in there and remove some of the comments and unused color profiles. So each image has some metadata baked into it, right? Perhaps what camera was used to take it, what lens, what time it was taken at, its location, things like that. Things that your users probably aren't really interested in or ever going to look for. We can remove those. We can remove the color profiles that are not actually used in your image, right? Here I'm using Image Optum and I'm able to cut this file size down by a little over 14%. Now, Image Optum works well on a Mac machine. There's also PNG Gauntlet for Windows. Does anyone use CodeKit by chance? A couple of you? Image Optum's actually built into CodeKit too. So you can just start compressing your images as you're already compressing other files too. So thinking about the long haul and getting these ships in order, we have to focus on maintainability and ways to keep our code organized, modular and performant. Where's a good place to start inside of that? I would pose to you to build a style guide, right? Find a library and work from that. Twitter Bootstrap and Zurb Foundation have done a great job sort of outlining these for us and we can look to them and see what they've done. We don't have to copy them but they can get you pointed in the right direction. Keep in mind that your instinct shouldn't be to write new CSS long term. The goal should be to write HTML and see how the styles are inherited and then move from there. Review some of these methodologies and these modular practices, right? Outlined by Nicole Sullivan and Jonathan Snook. And continually test and refactor your code. To go off and do this all at once is a really ambitious goal. But as you go into a file and you're working in it, refactor it, take a look at it, right? See what else it touches and how you can start to clean that stuff up. Long term as you do this, you continue to do it and you get your team doing it, your code base will start to tune and fall in shape. There's tools like CSS Lint and the inspector and page speeds that will sort of help point you in the right direction here as well. That is what I came to talk about. I write about this stuff at learn.shehow. I write these guides on how to learn how to code. Teaching at the Star League, I just started publishing all of my curriculum for you guys to check out and I have a lesson specifically about what I talked about. And I'll also be doing a workshop at South by Southwest about this stuff in a little more detail and we'll actually get our hands on and maybe play with real Legos. And the slides can be found over here at the Bitly link. The speaker deck, I checked it earlier. It was like acting really weird. It was saying it was processing the slides. So if you don't get it, maybe check back in a little bit and I'll definitely tweet when those slides are up and actually working. Any questions? Absolutely, yeah. So his question was, the alert example still didn't seem quite dry. You're adding extra classes in there and the same thing could be said with buttons, right? If you have a default button class and then add extra classes, you absolutely could use an attribute selector to say this does that class start with alert dash and then you add in the default alert styles and then basically expand on those as you move on. Browser support's not gonna be through the roof for that. So that would be an issue. But I like your idea, I think it's great. I do it from a pre-processor standpoint where I use extends or something like that inside of SCSS or SAS to add that stuff. But yeah, you're right on target. All right, well thank you guys.