 All right, so I'm going to talk a little bit about this. Talk a little bit about organizing your CSS and SCSS. All right, so just to give a little intro, my name's Joel, Joel Pan. I'm currently a friend and developer, but I wasn't always, for eight or nine years, I was actually doing digital marketing, and I've only in the last two years or so I've come back to programming. I did my degree in computer science, but I didn't do any programming for about eight or nine years. Okay, so I grew up programming. I learned basic when I was about five or six years old from some us born book, from the PC, Pascal C. Discovered HTML around 1995, I think, with Netscape 0.9B, I believe it was, and using some amazing piece of software called Hot Metal Pro, I don't know if any of you remember that. But the fact is I've only been professionally a friend and developer for about two years. So I'm a bit of a nuke. I'm hopefully inexperienced, and that should tell you a little bit of something about how you can be qualified to come and speak here, which is you don't have to qualify at all. All right? What's the motivation behind you change from nine-year marketing to product? I decided I didn't want to deal with clients anymore. I was tired of agency life, so I went to work in-house, and somebody offered me a programming job just very surprising, considering I hadn't been doing programming for about eight or nine years. But I wasn't going to complain, so I took it, and that's what I've been doing. All right? So a lot of what I'm going to talk about later, some of it may be very basic, some of it may be a little bit new. I don't know, but whatever it is, I'm here, so deal with it. Yes. All right, so just a quick intro. So CSS, if you're dealing with large projects, your CSS can very, very easily get very big. Right? Some of you may choose to put all your CSS into one file for an entire site. Some of you may have different CSS files for different pages, depending on how you organize or structure your own CSS. With whichever the case is, the larger your site gets, the more CSS you have, the harder it is to figure out where is this particular rule, where is that declaration, how, why is this particular thing looking in this way when it's not supposed to be? All right, so your selectors are all over the place, and even within each lecture, your declarations to properties may be inconsistent in order. This may or may not be an issue if you have a, for example, if you have a rule with lots and lots of declarations and you're trying to find that one Z-index rule that you just can't find. All right, so quick disclaimer, these are just suggestions. You don't have to use any of them. These are not best practices. They're really just suggestions. How you can organize your CSS if you want to. All right? So this is how a plain CSS, very, very simply, and I'm sure a lot of you already do this, just simply organize your CSS around specific logical blocks, where as your header, put all your header rules together, there's a footer, put all your footer rules together, give it to your navigation bar, your content page, your article, put all those together so they're easier to find. Even better, if you do that, do a table contents at the top of the CSS file. So it's easier for, not only for yourself, but if you have team members working on the same CSS, it's easy to check, how far down should I scroll for this particular rule, for this particular book of rules. So this can help, obviously, you have to maintain it as well as you add more blocks. Another thing that you might want to do is to indent the rules. So it's easier to see which rules are nested under other rules in terms of the selectors. Obviously, you're not going to indent, sorry, you're not going to nest your selectors too deeply, I hope you're not, but for those that aren't nested, you can do this to help you see where they are. Another way to, another thing to do is to sort your selectors according to the Love Hate rule. So Link is an active hover, and this is just something to keep them ordered in a way that's consistent across all the different uses and across all the different rules. And the same thing for your shorthand rules. This is very simple. Top right, bottom left, right? It goes top-wise from the top. I used to have a lot of trouble with this because I always thought of it as top-left, bottom-right. I don't know why. And I always have to go back and correct things, but just remember this top-right, bottom-left, top-wise from the top. Or you can use the troubled acronym to remember this. Another thing you can do is to sort the properties. Now that I have given two examples here. One is to sort my box model. So you sort it in a logical way. You set the display first, and you set the margin, the border padding, and all the way down to your visual styles. So if you do this, it's easier to see, okay, is this a block or an inline rule, right? Everything's sorted in a way that makes sense, hopefully it makes sense to you. If this doesn't work for you, the other thing you can do is alphabetical, but whichever you do, do it consistently. Set a style for yourself, for your whole team, whatever it is, make sure you do it consistently that everyone knows what to expect. Personally, I like the box model rule. In fact, what I do, I'll talk a little bit later as well, is I actually separate the layout rules from style rules into different files. So that helps a little bit. Group your Z-index rules together. So this is one thing that you can do, and the reason you do this is, the Z-index is always a bit of a pain to deal with. It's always, you always have one element that's hovering over other elements, and you can't really figure out why, and you don't know where that Z-index rule is. So one way to do it is to put all your Z-index rules together, right? So it's easy to check what Z-index value should you put for this new element that you want to insert between two other elements, right? So have all them together in one block. Moving on to SAS, I assume that most of you here do know what SAS is. If you don't, it's what's called a pre-processor. Basically, it's kind of a superset of CSS that has some additional functions. I'm not gonna talk about all of them, but suggest some of the ones that will help you to organize your CSS. So firstly, imports. Imports are really useful in SAS, being able to separate all your files, all your CSS with different files, and then import them all into a single master.css or main.css that you can use for your entire site. Okay, and this will let you maintain different files for different logical blocks. This is just one example of how you might want to do it. For more, the other thing I want to talk about is variables, right? In SCSS, you can set variables that you can reuse later on. So for example, your primary colors, your secondary brand colors, you can set them as variables at the top of your CSS file or in a separate variables, SCSS file. And that way, you only have to change it in one place. And so this is very helpful. The other thing I want to talk about is SCSS functions, so I've shown their lighten. So instead of setting a hard-coded color as your light or darker version of the grand color, you know, use the lighten function to do that. So you only really have to change one color definition. Now, if you have a really large site, you might want to think about a more complicated SCSS structure. So you can put, for example, all your different modules together, your utility classes, you put your variables in one place, put your mix-ins, your different modules together. And at the bottom, you might want to put all your third-party CSS on place so that everything gets imported into one main CSS file that your users only have to do once. It's probably a larger follow for the first time, but after that, you know, it's cached in browser. So this is just one way I've, in my reference slide at the end, I've also included a link that talks about some other ways to organize this tree of CSS files. So this is one thing that I did when I was working on my site in the past two years, which is to separate out the styles from the layout tools. The reason I did this is because the site I was working on was not responsive, right? So it made sense for me to have a layout file, two layout files, one layout file for each medium that wants to be used. So one for desktop, one for mobile, for example. And that way, I could keep all the visual styles together in one place that's common across all the different designs, right? This can be a little tricky because sometimes, for example, the display, for example, here, display block, right? Typically display blocks under layout, but in certain cases, for example, when you're changing the list item, it's actually a visual thing. You want it to display without the bullets, right? So it's up to you decide how you want to separate them. It's as long as you do so in a way that consistently makes sense again. And again, to go back to the Z-index, if you're putting all your Z-index together, we also put it into one file by itself. And that way, you always have one master Z-index placed to look for whatever definitions or whatever values you're putting for the Z-index. Again, for sorting, for SCSS, it's a little more complicated. You have extends, you have includes, you have your nested selectors, you have your nested pseudo-selectors. So this is, one thing again is to sort them, right? Sort them according to how you're going to use them, all right? So one suggestion is to put the extends, start with the extends, then put it includes, then all your styles for that selector, then your nested pseudo-selectors, your nested pseudo-classes, pseudo-classes and pseudo-elements, and then your nested selectors, right? This is, as long as you do, again, as long as you do consistently, but this I think is a good way to make it clear which are the styles that belong to this element and then which are the styles that belong to its children. And just as a quick aside, if you're going to do SCSS heavily, please use source maps. It will make your life so much easier. Having, being able to see which source SCSS file this rule's coming from, instead of having to dig through all your SCSS and hope that you always know where that rule's coming from. So that's it really, that's all I have to share. So what I'd like to do is to ask all of you to share one of the things that you do to organize your SCSS or your SCSS. What are the tips and tricks that you have? Yeah, go ahead. I always sort of remember, it's just the one like... That's a quick one, okay. I just want to say that I sort my rules alphabetically because I can never remember the organization or display the other box, whatever. So, and like it's hard to communicate that to teams, but I can't remember it. So I just say that we would just do it alphabetically and at least you won't make mistakes. When the box model concept came out, it was pretty common to see at the top of every SCSS file not exactly what the box layout was, sort of tell you the display, then the margins and stuff. But it actually showed, I can't remember. Exactly. I think alphabetical drawings are the same when I come across that because logical grouping helps, especially if you're jumping around. I have a question about me, which I think is a boss model for an organization, right? Is there anything that exists that will help developers? I think I've been told that that you're running more culturally of SCSS file than automatically grouping for your SCSS stuff. Remembering it? Yeah, I mean, I hope SCSS has something to do with that. There's only, I don't think there's an alphabetical thing. It's a bit almost colorized, but I don't know. Hold on, hold on, hold on. No, but you see this one which does the grouping by category. No. I don't think you saw it. There is one, Jen, sometimes it's something. Yeah, it's something about. I didn't use it, but I realized it's kind of broken sometimes. Yeah, but what I do is, I get like an interface, so it just tells me, when I use ethanol supply, like it doesn't tell me, it'll tell me the order and I'll just change it and over time I'll kind of figure out the order myself, yeah. The best way of enforcing rules, I think, is with a mentor rather than using a processor. Because if everyone uses a processor, you don't learn anything. Whereas if you're doing something like browser prefixes, post-CSS stuff is fantastic, because you shouldn't have to remember if it's dash, moles, dash for this one, if you still need that, or if there's an MS prefix or whatever. So those things are really handy when that happens. Anyone else, questions, comments? Yes. Okay, so when you're writing code that says JavaScript, you want to do variables close to where you have them, right? But in CSS then, the convention is to have all your variables into a gigantic microscope where it's all. So there's one thing I struggle with, I think I should say this is like, where do you put some of the variables? And most of the time you have colors that kind of use everywhere, you make sense of them, your giant variables is a CSS file. But if that's not working on a very specific animation and I keep my variables there, it doesn't make sense for me to keep my variables in the giant variables file, because it's only when you use them in one place. But at the same time, there's this drawing here where they have all the variables there and some random specific ones nested inside the rules. So I don't have any views on that. I think having the variables stored together at the top of your, or the separate file is usually that really applies for global variables. If you have stuff that only applies to a specific element or a specific block, then sure, I mean, put it wherever it makes sense to you. I think where I, for me, what I experienced was a lot of times I would assign a variable in a block and then later find out that I was gonna reuse the color somewhere else. And then either I would have to remember to move the variable out in front or I forget to do that and then I realized that I get errors because in the other place that I use the variable is not exactly yet. I think you've got two things you have to think about. As a basic rule of programming, you declare something as close to where it's used as possible. So that's easing the confusion that you're talking about. But then, since everything in CSS is inherently global, you are going to start reusing something. So it's more down to what the variable actually is than anything else. If you've got a color, if you just let people declare colors wherever they like, you end up with my company, where we have 62 different variations of our company blue and that's just the blue and just in one project. So colors should be in a global. Something else, if you've got a custom animation, then maybe you want it within a scope. Actually, animations probably should be global as well. Mix-ins, you might have close to where they're happening. Right, yeah. I suppose I declare variables and mix-ins too which is like you're just going to scope a mix-in. Yeah, I had one I did last week, I think it was a custom button styling within a particular scope. And I just declared it at the top of that file to run anywhere beyond that. I think that kind of makes sense. Anyone else? Right, within that you can define a global, but and then in the file that you want context to be, you'll be defined another variable that reference the world global world. Then you get a context and then you still have a global reference. So you just need to remember that in this file, it's another variable, I'd say is an animation A, a color. So when you update a color, they get to change as well. Yeah, but that's dangerous still. Because if you know it within the local context, you might still want to use it somewhere else, but I think it really depends on what you're actually putting in a variable, I don't know. I think again, all these are just suggestions. Now use them according to what makes sense for your project. If you're very certain that this particular variable is only going to be used within this context, then sure, put it where you need it to be so that you can change it easily within that context. I think that's fine. But if you find that it's going to be used somewhere else, then you're going to remember to move it nearer to the top of your SCSS structure. I think Chris is right. The problem with SCSS is that all these decorations are global. You know, I don't think we have scopes. There is no SCSS. Yeah, so you have to be careful because anything you declare is going to be available to all the SCSS below that point. That actually is local variables in SCSS. So if you declare, like, say, button, like you create a button class, you can do, let's say you have global colors elsewhere in a variable form. So you can have, like, maybe blue. And then there's, like, the hex color of blue. And then let's say you have a button class. And within the button class, if you do something like a dollar color and assign another value to that dollar color, it's going to be only within the class. Yeah, within the class block. I can remember that. So that may be kind of helpful. What's a class in SCSS, though? Like, is it like a big space or something? Or, oh, within a class iteration? Yeah, within that. All right, fair enough. And available to all those children, I assume. Yeah, yeah. But then you don't want to run into nesting things too deep. Because nesting things too deep is the work of evil things. That's good. Okay, else? Just one thing about managing Z-index. I think if you happen to use SCSS in your project, SCSS has an index function. So it's actually possible for you to write a function to take in. So what you have to do is you have to use a SCSS list. So it will take, it will be the order of your list. So what I do is I have a function that does that. So what happens is, the order of how you declare your layers matters. So you can name it, like, maybe you're going to have fixed navigation menu, and you want that to float on the right top. So that would be, you put that last, so maybe you could call that layer nav menu, I don't know. And then maybe you have something at the bottom that, like, I don't know, carousel. So the carousel, so the order matters. The one at the bottom will have a higher index than you. So it's not zero index, it starts from one, I think. So, but when you compile the SCSS, it's one, two, three, four, five, and if you realize that, oh, I need something that goes between the layers, right, you can just put it in the SCSS map. And when it compiles, you will just update the rest. So that's actually quite helpful. If you're not using any third-party CSS, then that will probably work. But the problem- If you are using SCSS, you can use that. Yeah, the issue that you may run into when you're using third-party CSS is that they have their own Z-index declarations that you need to override, or you need to make sure that your element goes over some third-party element. So is it third-party CSS, you're saying? Like, let's say you include the jQuery CSS or you include the bootstrap CSS, and they have, let's say they have a Z-index. Simple solution is never, ever used it. No, it's not. It's not. It's not. I wish Viper always had something. I mean, it's all right, yeah, so. Yeah, but then they'll update it and yours will still work. But for a Z-index, I kind of keep it in the front-end here as well. And then I just inject it straight into it and leave it there. This leads to a question I have for anyone who wants to answer. How do you handle third-party CSS, which is what we come onto? If you need to do an override or something, do you put that in the same location as you would somewhere else? Does anyone have an interesting way of handling that? Or do they try not to? I would say if you do have to, you don't, you never modify the original file because everything I've updated, your intent goes every day, but if you use, even if you use CSS or SCSS, I think it's still good to section it in its own section under overrides. So it's easier to differentiate your own original styles with, because usually if you use a third-party instance, they may or may not follow your class naming convention either, so it kind of gets messy. So for me, I would try to put in a separate SCSS file, or if I'm just using pure CSS, just put it in its own section, like the way the section is stuck, put it in its own section under overrides. That's just how I do it. Very good. Anyone else? Yes? So something that I've been a little bit more interested in, instead of just like including the pre-built third-party CSS or framework whatever, and overriding it, a better option, if you can, is to include the sources and then build the framework in your project. So for example, what I do right now is when I'm using Bootstrap normal customization, I always include the Bootstrap SAS project, and then I copy out the entire, let's say variable, the CSS file, put it into my own file and make changes there. So that way I'm not overriding it, I'm just rebuilding the entire Bootstrap. Yes, I'm maintaining a framework within my company and that's the method I advocate, basically. I've split everything else and I've felt it's easy to do that, but that's the best way of doing it, so you basically create your own fork. Yeah, pretty much. The problem with that is you've got an instant legacy, but that's your burden as the maintainer. Anytime the main one updates that you need to make sure that you're still within scope. Any other questions, comments? Everyone else's CSS is perfect. That's good. Thank you, Joel. Yeah. Joel has references. Thank you.