 I worked really hard on this next slide. So everyone, please look at the screen. It is the best part of the entire presentation. It gets better. So you can also download and kind of follow along or cheat and skip ahead and fall asleep or something. It's m5l.co.wcus to download a PDF. So I have to move pretty quick. And at a certain point, I will have an option for questions. Or we can talk more about performance or something. So just heads up. To start off, I want to talk about the tools you need to use. If you're going to do pretty big CSS projects, first of all, you've got to use version control. Definite must have. I don't care what you use. Get Subversion manually copying and pasting folders is OK, I guess. But version control is big. Use some build tools, gulp, grunt, Google all of those things. You're going to want an auto-prefixer, for sure, and definitely some kind of linter. I prefer those grunt and gulp build tools just because they're a pretty operating system independent. First things first, you need a preprocessor probably, or a post-processor. If you're in a post-CSS, it's pretty powerful. And you can actually combo them. And you need them for a few reasons. The key features are imports, being able to take a whole bunch of small files and put them into a big file for sanity's sake. You're going to want some variables for colors and maybe breakpoints, and that's about it for most things. And then some mix-ins, which are good for reusable code. Everything else doesn't really matter too much. You can use some functions for M conversion and stuff like that, but real quick, import, again, allows you to take a whole bunch of really small itty bitty files, which are easy to read, and put them into one big file. This is not ideal if you're maybe doing a pretty small site or theme that you can. It's meant more for those projects where you have hundreds of components and endless possibilities of how they're arranged. Variables are great for colors. You should name them with the color. Don't be like color one, color two, color three, please. And then you can have, you probably want to style guide that lists them so people don't start just dropping in hex codes or whatever the heck. You might also want a variable for white. That's kind of a, you know, you can do it if you want. Well, just because in the output, anyway, that's post-processing stuff. And then mix-ins are pretty rad. Don't do extends. I don't think I mentioned that later on. Don't do that. That's really bad. But a mix-in is just a piece of code that you're reusing all the time. And this is an example of something we had that's pretty small. And it just lets you include this mix-in with your component that has a consistent animation. That's all it does. It's pretty straightforward. And it has a value if you wanted to change, I don't know, the percentage of the gray it looks like. So those are really key. Now, for what I really want to talk about is CSS and a complex application, like how do you set it up? How do you deal with the global scope, things like that? So starting with the global scope, everything in CSS is a global scoped thing. So when you style an aid, it applies to every single A ever, and there's no scoping of components. And it can be frustrating if you've ever dealt with that. It results in unexpected styling and collisions and things like that. And the way it's designed sort of encourages you to increase specificity to get around it. And a quick thing about specificity, straight MDN copy paste, it means a browser uses to decide which CSS property wins basically, which one is actually applied versus what you hope was applied. And a quick example of that is the lowest specificity is just styling a straight HTML element. And classes is next up, then IDs. And you can override that with inline styles and important but don't, please, use either of those things. So increasing specificity is bad. It's contagious. The more you do it, the more you have to do it. WordPress admin is kind of a good, bad example in that if you've ever tried to add or override an icon in the sidebar, the specificity chains pretty intense. It's like six selectors in a row, some of them overqualified. And there's nothing you can do about that unless we actually rescope WP admins classes. So how do we manage this and keep specificity low for headache purposes to keep us all sane? And this is kind of what I'm going to tell you what kind of worked for Calypso when we were building it and any other projects I've been on lately. First question was, do we use a reset or a normalize? And just so you know the difference in normalize is just a base styling of all of the elements. So that they all look the same in all the browsers. And reset completely resets the text and anything like that into just straight body copy. It's very predictable. And you should definitely go with the reset if you have a pretty complex thing. It does require that you style every component and element. But it is super predictable. You're not overriding the same thing over and over again. For example, if you add a margin bottom to a p tag, I'm sure you've run into it where you have to get rid of that margin bottom over and over again depending on what you're doing with that p tag. So in this case, you're doing a more additive class. You're working with classes in a more additive way than subtractive, which is pretty good. It also gives you a really, again, unpredictable base to work from. Next thing, naming conventions. These are awesome, and people fight all the time over them. But I like BEM naming patterns. I don't really care whether you use under scores or dashes or whatever. But for those of you that are not aware, BEM stands for Base Element Modifier. So you start with a base, which would be like header nav. And then you have an element, which could be an item in the header nav. And the modifier, which could be current or active or focused or whatever. And that allows you to have some semblance of, A, you know what's going on when you read that selector. And B, you don't have to nest things, which is pretty ideal. One of the biggest things when you're doing this is to make sure your names are clear. Don't try to be efficient and use two-character names or prefixes and stuff like that. It's just not readable or maintainable. And you can use post-processing to obfuscate that or make it really efficient if you really want to. Like, that's bad. Don't do that. That's better. You can actually read it, customize or widget. You know it's active. So again, use BEM. And being clear is pretty important. Let's see. Classes only use classes to style things, like only classes. Don't use any HTML elements. Don't use any IDs. Just use classes. This is super important and can be frustrating sometimes. But you pretty much want to avoid classes. There are times when it makes sense to, for example, if you build a content reader or feed reader of some sort, you're probably going to want to do some scoped styling of base elements, like pre and P and all that stuff, so that the people's posts look really good. But outside of that, don't use HTML elements. And let's see here. It keeps specificity low. It decreases overrides if you're doing a really good BEM class naming system. And it's pretty reusable. And I'm going to do a really bare minimum example, where if you had styled a list item with just a bottom margin, to override that, you have to at least use a class in the list item. And let's say you have another component called fancy list, which extends list item a little bit. You still have to also override it to match it kind of. Actually, that was a terrible example. My bad. But do something more like this, where it's additive. You get a margin bottom. And then if you want to override it, use another class. I totally, this is totally wrong. But yeah, do that. There's another example coming up that's way better, I promise. Don't nest your selectors at all. This is, a lot of you have heard this preached a bunch of times, but it's pretty true. There are situations when you want to, when you're extending another component, you want to use that component's class rather than adding a class to it and trying to override it that way. But in this case, I just did a quick example that I've seen a zillion times. It's super common in WP Admin for things like this, where you've just got all of these overrides that become pretty unpredictable. And then you have to at least match to override their styles. And if you want to reliably override their styles, if things get mixed up in the import, you have to increase the specificity like one more step, which is horrible. There's actually, there's a class I wrote right now in core. That's like button, button, button, button. There's an apology next to it, which is how you know you're writing it correctly. And this is a better practice. So you have list and then list item and list button, and they're all at the same level of specificity. And then to override it, you could just keep it at the same level, which is okay if you know the order. But in a complicated app, things get moved around. So you're gonna wanna bump it up and actually extend it via having that child component nested one level inside. Try to keep it to that. And like nesting hover and stuff, that doesn't count, so just do it all the time. But again, like nested selectors are pretty contagious as at WP Admin again shows. It causes hugely increased specificity and has code portability issues. And there's a lot of speed issues because of it. Another thing that's kind of counterintuitive when you're getting into preprocessors is media queries. You're gonna want to not do this. Like it seems right to have all of your stuff that goes inside that media query like together, but that's wrong because it's not maintainable. If you remove something, you have to go and manually figure out where the heck that thing is if it's being used by that media query or if it's being used by another slightly similar media query. So there's often in projects that do that like a random thing that somebody forgot to delete that does nothing, so that sucks. And then I do recommend nesting it. So if you're using SAS for example, you just nest it right in that element. It keeps everything together. You know exactly what's happening. It's pretty awesome. So again, keep media queries with selectors, components. This is the part I wanted to get to. We componentize the heck out of Calypso in a really good way. It's kind of wonderful how good it is. Like we just rearrange style sheets and I say we being me one day just to see what would happen. Nothing broke. That's pretty impressive. Like if you've ever rearranged stuff usually there's specificity issues and none of that. So that was pretty cool. So a component is just like a single purpose interface pattern and to give you an example, this is the first component I ever wrote and it's kind of stupid. It's just a white box that you can make another element if you want. And then below it you can see a better example of a component that's a site and that uses I think a couple of components but it lets you like kind of Lego things together and that's kind of what you wanna go for when you're building an interface whether you're using React or not. Like when you're building the CSS that's how you should think about things. So they can be really small. We have components for like a button instead of styling the base element and here's kind of what the folder structure looks like. We've got the component which is the component name and then index.jsx and style.scss for each component. We don't keep all of the styles together in one big style folder. Instead we keep them with the component. It makes them pretty portable and really nice and easy to see everything that's going on at once. And then we've got a readme that talks about how you implement the component and some like tests and docs and stuff like that. We also name the styles like the selector the same as the component so it's really easy to find where that style is being affected without even needing like SAS maps or anything like that. Oh yeah, they should be portable, do that. And they should be really simple like having three lines of CSS for a component is awesome. It again feels kind of stupid when you've been writing lots and lots of CSS and it seems a little bit slower to have to do that but it's awesome, I promise. And refactoring is really easy because of it. So often when we're writing CSS, get into a part where we need to, we find something that's written badly and it turns into this big long rabbit hole of like fixing 80 different things in the CSS and you forget why you got there in the first place. Like two days pass and you still haven't fixed the thing with components and thinking everything because a nice little scoped tiny little package it's really easy to refactor and not get lost. And then file structures, this is my favorite subtitle, like opinions, everybody has one they have opinions about. Stupid. But here's kind of how we have our structure set up use what works for you. This is kind of what calypso is it's got a root folder and then you've got a style sheets folder that I told you we didn't use but we kind of do and all that's in there like some utilities and mix-ins and color variables and like that's about it. And then we have everything else in a separate components folder that contains that component file structure you saw earlier. This is pretty important. It means that almost no real styles are in that folder. Like you don't even have to go in there very often unless you're tweaking a mix-in or getting a color variable or something. And again, that's what the closer look at the utilities we keep when we now keep all of the mix-ins separate. So there's one mix-ins file called mix-ins that imports all of them into the main style sheet which is probably I don't know stupid but it works. And the smart part is that we broke everything up into individuals it makes them really maintainable. It's not this vague folder or this vague file full of all of this mystery CSS. It's pretty obvious what they do by their name. Again, be clear you can have like a 10 sentence long name if you wanted to because it's just an import doesn't end up in your CSS. So be really clear, have a little description how to use it and try to only use very repeatable code in these mix-ins. If you need a mix-in for a component again it should be with the component. So yeah, some summary there. Skipping because of time. See setting rules, this is also pretty important for working on a pretty big project. Auzar you're not the only person. So you gotta have some documentation. You need architecture rules, you need CSS code standards and you probably want a really solid contribution process. That's probably the most important one. Like CSS code standards are awesome. Like having some rules for file structure and how you do that makes things a little more consistent but having a good pull request review process or whatever it is, a track ticket, it's really important. That'll make your code better than anything else and in currencies like learning and all that fun stuff. So you don't have to repeat yourself a thousand times. Here's two really good code, or CSS tile guides. The SAS guidelines is awesome. Hugo Giroudel wrote it but it's super opinionated and it's definitely like you need to do this, you need to do this, like there's no other alternative. There are, but he's probably right. And then the WordPress CSS standards which is pretty close to accurate minus the like tab indent thing. Here's an example of how this works in Calypso. Before we open sourced it, this is kind of what our pull request page would look like where we just had like a couple hundred open at a time and thousands closed. But you notice every single one of those at the top has a needs review tag or something. Anyway, when that's on there, it means somebody else that's not you needs to go in and code review it and look for issues, improvements, that kind of thing. And until that gets resolved and people have said, hey, that looks good to me, you can't merge it. Like that's the end of the story. It feels slower, but you learn a lot in the code quality skyrockets. And we liked it so much, we did it with the design too. So any design thing that changes visually, a copy, we add that same flag. So a designer that's not you has to go in and be like, cool. And then you can merge it. Again, it encourages learning, it's great. You don't have to repeat yourself a thousand times to people when there's just one pull request. You can be like, hey, do this on this line. And they do it forever. It's awesome. Let's see, open source, which is all why we're here. Nason gave a talk about backwards compatibility and supporting like user trust yesterday. And that's the biggest consideration on any open source project generally. It's really easy to add stuff and terrible. It's really difficult to remove anything. And that's just because we don't wanna break interface patterns. For example, there's great ways that we could rewrite the CSS, but we could never change a class name. Or we would break, if we change a class name on button, every plugin would break in interfaces with WP admin. So we just can't do that. There's ways around it. We can improve it subtly, maybe improve the selectors, but we can never just change things. We can also never remove like icons. Like if you've never dug into the images folder, there's like really old PNG icons from like the first versions of WordPress, because some plugins use them somewhere. Everything you add, some plugins gonna use, which is awesome. So this actually kind of scares me when we're adding new styles or class. Like it's really cool to be like, let's try this interface pattern. But then the plugins are like, let's try this interface pattern. It's awesome. And it turns out that interface pattern might be the worst pattern, but now a bunch of plugins use it, so it's there forever. Wow. And another thing about open sources that often comes up is like, why don't they all use Sass? Some of them do when it makes sense, but you really don't need it. Like it's not super necessary at any level. That's what build tools are for. But we also kind of use Sass a little bit for the color functions and stuff, but at some point we'll remove that. Let's see. Browser support's super important. Try to be when you're coding, thinking about progressive enhancement. It's not hard to do. If you use that asterisk like box sizing, border box on everything, which I highly recommend. All of a sudden, IE8's like almost no extra styles. So you can do that. You can think progressively. Like you can add some sweet animations that don't really infect how users use it, things like that. Again, use auto-prefixer, it's awesome. That accessibility, like that text on the top, all a bunch of talks were squished yesterday, but I would rather maybe squished and have that transcription up there. And thank you whoever's transcribing whoever you are. Thank you, you're awesome. But it's really important to include everyone and make sure everyone can use your site. And he talked a little bit about that yesterday to via like the browser support, but here's a sweet quote I found. It's bad enough to have poor accessibility on your site, but it's much worse to encourage poor accessibility on thousands, which is something you have to think about in an open source project. In this case, it could be extended to like, I don't know, gazillions, but it's, again, I can't stress enough thinking about accessibility and making sure you've got focus styles and that tab navigation works. All of that is super key to having a good open source project. Kind of the end. I'm like L'Arsted, work at Automatic, I'm a designer on some projects. Jepek. But I'm not done yet. I have a short time. Okay, so I have a question before you ask any questions. Would you rather I do questions or would you rather me go to a quick performance section that's kind of front-endy and raise your hand if you want me to talk about performance? Okay, we're gonna talk about performance. Okay, first things first. When you're talking about performance, you gotta think about page speed, like the load of the site. And one of those things that comes up is you have multiple CSS files or one gigantor file. And it kind of depends. The one mega file is pretty great until you get to like WP admin size. And even then, it's not terrible when it's compressed and gzipped. Unless it's blocking rendering fonts, web fonts specifically. But multiple files can be pretty cool too. Like for example, if you've got just a ton of styles in your big file that are only used on one view, why not just load it on that view? Like if it's a view that's not used very often, don't load it there. If it's not your first page load, you can like asynchronously download or I don't know, ask a developer to make it happen without initial, slowing down the initial page load of the site or app. So that's a really good way to go. Another thing that comes up is inline styles. How many of you, by show of hands, how many of you are interested in like using inline styles to solve all the scoping problems via JavaScript? You're wrong. All two of you. I mean, it's really cool. It's fun. I did it like the other day. But whatever, there's all these problems you can solve with just like some naming conventions and some rules. So that's, you can do some fun stuff with the inline styles too, but don't do it because they're pretty contagious. You can only override them with other, like replacing the inline styles or, I don't know, it's not ideal. So, and if you use them, you have to use them everywhere. And they're not really cacheable, which kind of sucks, unless you have a big JavaScript, you know, whatever, it can be cacheable. Everything has an asterisk that I'm talking about, but about caching, cache what you can. CSS, even large files are generally pretty small and compressed and minified. WordPress.com has a pretty big one and it's still not very big, but the problem with it is that we have like 60, I don't know, about 60 people touching Calypso any given day and several commits a day. When I say several, I mean like probably 40 or 50 and a lot of those touch on CSS, which means every time that CSS changes, Cache Buster, which kind of sucks, but it's a pretty small file compared to, I think it's even smaller than most like avatars, so it's not that bad. Front end performance, avoid repaints, like don't use width and top and left to resize things. That's super slow and especially if you're on a high definition screen or a phone or something slow, it's like unusable. Thank you, parallax sites for demoing that for everyone. But here's some safe transitions that you've probably seen, but opacity, position, scale, you can do a ton with in like no time and it's pretty performant. One thing that's not an animation that's pretty bad is box shadows. Fun thing to test is go to a GitHub diff and add box shadows to the span element and then try to scroll. You can't, this is the short answer. The performance is just really bad. So you can use them in small amounts, but try to avoid using them in bulk. Like if you have a thousand avatars on a page, maybe box shadows, not the best place for that. And again, avoid HTML elements as selectors because selectors are read from right to left by the browser when it's rendering them, which means in this example, it's looking for every single span in the page first and then it looks for every single span inside of an A and then every single span inside of an A inside of an F. And just a quick search in the inspector, like WordPress.com dashboard, no, WordPress, just the WordPress dashboard. There's like over 150. The Facebook page is 300 plus. And GitHub diff, like small GitHub diff is 2000 plus. So that's gonna be a very slow selector compared to just targeting the class that's like, I don't know, GitHub diff ad or whatever they use. So again, avoid HTML selectors, be very careful, avoid the asterisk. I don't really mention that before, but outside of a reset and setting your base styles, you wanna kind of avoid that, they're pretty slow. And now I have a very short amount of time for questions, actual questions. So let's go, ask me something hard. That's not about less. George, you can ask me questions anytime. Yeah, but this is for their benefit. How do you feel about the important command and are there any instances where it's worth using? There are instances where it's worth using, but only to override some crazy element that another service has added to your awesome site, like O-Lark, because they use important on everything. It's also okay in like HTML emails because there's web browser clients that you actually need to use it, but for every single other thing, don't use it. Two questions, actually. One, can you recommend any CSS testers? Yeah, totally. My second question is, you recommended doing like a button and then your media queries, then maybe a list and their media queries. Is there any performance issue was having multiple media queries? Not at all, I promise. To answer the second question first because it's more fun for me, I've got like code pen demos that push that to its limit where there's literally like 10,000 media queries on a page. There's no performance issues there other than there's like a huge file, but in terms of rendering, not at all. You can have thousands of them and I've seen people do it with thousands and thousands of them just to test their performance. There's no performance issues and also you can use post-processing to kind of glob those together if you wanted to. So again, it's more about maintainability but you can actually come up with that big end result with just like three media queries or whatever that makes you feel really good, but it's not super necessary. And to answer the first question, there's like CSS stats, there's one I use in the browser, I'll like dig CSS is pretty cool. CSS perf is interesting. And then there's a lot of other tools just baked in the inspector that you can now use to watch selected performance but CSS perf is like a browser extension for Chrome that will just run a quick performance test and show you how many milliseconds it takes these selectors to hit their target. Generally the slowest ones are gonna be HTML elements or asterisk or really, really long chains but the long chains aren't as bad as asterisk or spam. You mentioned earlier about not using extends. What's your reason for using mixins for like a clear fixes opposed to using extend for that? Okay, so extends are pretty controversial in that they're cool. The idea of them is sweet. If you're not familiar with extend, if you write net at extend, it means that every time you use that you call it with your button and I don't know, link. Let's say you use those and extend some like animation to them. It's just comma separating, adding them wherever the extend is written. So it actually has some specificity issues because it puts them right where that extend is written. And on an app like this, it can be really, really difficult to figure out what's wrong there. Another thing is they're not helpful. They end up in this big huge glob of selector nightmare and it's just better to repeat the code like exactly the way Gzip and other compression things work is like if there's exact hunks of code that they're the same, just repeats them in a really efficient way. So it's not super necessary and oftentimes the bugs that you're gonna encounter doing it are not worth it. Like it's just not super useful. It's better to just try to mix in. There's better answers than that on the internet like stack over, I don't know, somewhere. Chris Coyer probably wrote something brilliant about it. Any other questions? No one's complaining about splitting up files. Damn me. All right, cool. Well, thank you.