 Good evening, everyone. First, I want to thank Talk.css and Hacker Space for hosting us. I know it takes a lot of effort to make this happen, so thank you so much. My talk today is going to be Introduction to Flux. It's actually red flox, and my name is Ayaka Sotaki. I just want to have a quick show of hands. Who has heard of flox? No one. Okay, great. This is going to be something new to you all. So flox is actually a CSS organization methodology or CSS architecture, and it's actually quite widely used in Japan, but probably unknown in every other parts of the world. Okay, so let's get going. Agenda for today. I'm going to give a quick introduction of myself, talk about some potential problems with CSS. Quick tips to writing maintainable CSS, what flox is my refactoring experience and some problems with flox. Okay, so starting, my name is Ayaka. I'm a freelance web designer and developer. I'm Japanese, but I was brought up in Singapore. I was teaching web design in Japan, and I co-founded a web development and design company in Japan. Yes, and you can find me on GitHub and Twitter and everything. Okay, so talking about some problems with CSS. When I usually have tasks for CSS, I usually get assigned an ongoing project or a new project. So I think that's the same with you all. Whenever I go into an ongoing project, I'm very excited. I'm like, yes, I get to see the CSS structure of this company, like let's go, and then I go in and I see everything's on fire. So sometimes I see like dot orange and inside the selector I see like color green. And I'm like, how could be this dot orange? So I'm guessing they changed their brand color, but they didn't update their selectors or something. So it's either it's already on fire or I start a new project myself, and I start writing my CSS, I structure my CSS, and I'm like, yay, this is going really well, like this looks really great. And then after a month, I'm just like maybe like a new project comes in, like oh Ayaka, can you please add this to your project? I'm like, sure, where should I write it? Okay, I'll just put it here for now. I'll change it later on. And then about two months later, I'm like, okay, this is getting a bit itchy, but it's okay, I'll just carry on. And then after like a five months or six months, I just find myself drowning in CSS. And so what I want to point out is that there are some potential problems with CSS, and they can be due to these four factors. So maybe you first, the impact of changing each CSS is really hard to tell. Since it's global, since CSS is a global scope, you can change one CSS, and it can change your whole project. And second, selectors fighting each other for prominence. So you might have a lot of nested selectors. And once you have nested selectors, you start using classes. And then once you have classes, you start using IDs to overcome classes. And then once you have IDs, you start using important to overcome that, and then you're like dead, because you have no way to overwrite importance. So that's the second problem. And third, you start repeating yourself over and over again. So maybe you're writing CSS, and then you realize that you've written this code two weeks ago, but you just decide to leave it because you're not bothered to go back to it. Or even worse, you might even have unused CSS. So some people just like keep it there, like not bothered to delete it. And fourth, anyone can come and destroy your code. So you might have a new team member. You might not have the time to share your documents or talk through your code. Or even if you do, it still happens. Someone can just come and destroy your code. And this is some statistics. This is actually from sitepoint.com results. Ultimate CSS Survey 2017. So this is some statistics about how many people are actually conscious about maintaining their code, their CSS code. And you can see that the first and second categories, like these people try to maintain their code to some extent. So that's about 80% of the people. And the other 20% are not too sure whether they keep their code maintainable. So you can see that maybe one in five people are still not very conscious of keeping their code maintainable. And so to overcome these problems with CSS, I guess one way to overcome it is CSS architecture. And there's some famous ones, O, CSS, Max, Ben, and a lot more. And according to the survey, so Ben is the first, the most popular I guess. And the second, a combination of two or more people. And then comes Max, O, CSS, Atomic CSS, CSS modules, and so on. But what's surprising is that some people don't use systems. And if you add the first category and the fourth category, I think it adds up to more than 40%. So more than 40% of people actually don't use CSS methodology, which is a bit frightening. But it actually makes sense because CSS architecture is not very simple. There's many things to start worrying about. For example, how abstract do you want to make your components? You might have a simple case where you have an image on the left and a text on the right. So maybe you might come up with a class dot image left. But then what happens if you have a video on the left and the text on the right? So are you gonna make a dot video right class? You probably don't want to, right? So you probably want to make a dot media left and a dot text right class or something. So how abstract do you want to make your components? But on the other hand, if you make it too abstract, people start not understanding where to use it, where to use your components, like where should I use this component so abstract? Like, I don't know where to use it. So it's really hard to get that right amount of abstraction. And second, naming your components. This is sort of linked to the first question. But even something as simple as, are you going to name your buttons B-U-T-T-O-N or B-T-N is a simple problem, right? Do you want to name it differently or do you want to name it button? Because you don't want to have B-U-T-T-O-N in one part of your CSS and then B-T-N on another part of your CSS because that doesn't make any sense. And third, you want to think about how to categorize your components. Come in. Sorry, everyone's blocked the side, but feel free to come in. Yes, so as I was talking about, you have to start worrying about how to categorize your components. You don't want to have all your components in one file, otherwise you're going to have a huge CSS file and you're going to be scrolling through your CSS for your whole day. So you want to categorize your components, but in what way is the problem, I guess. And fourth, when to refactor an existing element. So you might have an element which you're thinking is not the best, but is it now that I want to refactor or is it me or it has to be someone else? So yeah, even like CSS architecture alone, there's a lot of things to worry about. And you can realize that CSS architecture is really hard because CSS is so fragile. It's like you're trying to fix this puzzle and one part just always seems to pop out and you can never get it perfect. Yep. Yeah, so I'm not an expert at writing CSS. I'm not, I don't think this is like the perfect answer, but I do have some tips to writing maintainable CSS. So first, delete unneeded child selectors. You don't want selectors nesting, nesting, nesting. You want short success on selectors, especially if you have a huge project. Second, don't use IDs or tags as selectors. I think these are quite commonly said. It's quite common, right? Like no one uses IDs. Like that's what you think, right? But then I saw the survey and then it says, do you currently use IDs as selectors in your CSS files? And 37% said yes. I'm like, why? So apparently there are some people who use IDs as selectors, but please don't because IDs have high specificity and you're gonna have a hard time overwriting your IDs. And also you don't want to use tags as selectors because it's gonna be, your CSS is going to be dependent on your HTML and you never want that. And third, use important as last resort. If you really have to use it, okay, go ahead, but try not to use it as much as you can. Fourth, create reusable class selectors if possible. So if you have some repeating patterns in your website, you're going to want to create a class that is reusable for all those patterns and not creating, not writing CSS for every single pattern. And the fourth, I call it the rule of three, but it can be the rule of four or rule of five. You just want to decide on the number. And what number that is, is that the time the pattern is repeating, right? So if you have, for example, if you have a card, with an image and a text, and if you have it once, you probably don't want to make it abstract, right? Because it's only gonna happen once. But if you're gonna have it three times, four times, five times, then you're gonna start wanting to create a class that actually encompasses all those three, all those cards. So I call it the rule of three. If you have three cards, then you want to make it a component. If you have three buttons, you're gonna make it a component. Yeah, it doesn't have to be three, but I just call it three. And this was already done. And then continuing, some more tips. Don't apply styles to JavaScript elements. I don't think a lot of people do, but I've seen places which does. And so if you're gonna use a class as a target for your JavaScript or as a hook, you don't want to put styles onto that class, or ID, or whatever. Next, no inline styles, please. Unless you're writing CSS and JS. So if you're writing CSS and JS, it's totally fine. But unless you're gonna do that, never, never write inline styles. I had one project where I went in and I saw inline styles all over the place and I was like, oh my God, never write inline styles, please. And fourth and fifth, I highlighted because this is the part which flocks can cover, which a CSS architecture can cover. So you want to break CSS into different categories and you also want to have a naming rule. Is everyone keeping up? Is everyone okay? Okay, great. Okay, so now we're gonna go into flocks. It sounds very new, I guess, like very different, but it's actually just the jumble of O, CSS, Max, Ben, CSS. So if any of you know Ben Showcans, oh really? No one knows Ben, okay, yeah. Or O, CSS, like object oriented CSS, yes. Then you already know a part of flocks or actually a most part of flocks. So flocks is a CSS methodology where you break your CSS into different layers or different categories. And there's six layers, foundation, layout, object, component, project, utility. And component, project, and utility is a part of object. So that's where the FLO comes from for flocks CSS. And you can see, if you want to see the directory structure, so foundation, layout, and object is at the foremost end and then you have component, project, and utility inside object, the object layer. And then I'll be talking about these layers individually. So first I'll be talking about the foundation layer. So this is similar to the base layer in SMACS if any of you have heard of SMACS. So you're gonna be wanting to write your CSS resets, your default styles. And also if you have like a brand color or colors you want to use throughout your project or typography, maybe fonts, font sizes, you're gonna want to put these in a variable CSS. And these are going to be inside the foundation layer. So this is where you build your CSS up on. And then you're gonna have your layout layer. And here you're gonna have your major components or your containers or blocks or whatever you call it. So examples include header, headers, sidebars, content areas, there's meant to be a comma there, sorry, content areas and footers. And so these components should only exist once in a page. So you should be feeling comfortable using an ID selector here. So like if you put a sharp in front of header, like sharp header seems okay, you're never gonna have two headers in your webpage. Sharp sidebars seems fine unless you're gonna have two sidebars, like on the left on the right, in which case you're gonna have a sharp left sidebar, sharp right sidebar, and a sharp footer sounds fine too. So for the layout layer you can use an ID selector, but since ID has high specificity you don't want to use ID. You can use a prefix of dot L hyphen. So you're gonna have dot L hyphen header, dot L hyphen sidebar, dot L hyphen footer, and so on and so on. And so in flocks we always use a prefix to differentiate between different layers. And also just a small caveat, in smacks, grid frameworks are included in this layer, in this layout layer, but in flocks it's included in the foundation layer. So if you want to use grid frameworks like Bootstrap or some other flexbox grids, you're gonna put it into the foundation, not the layout. Okay, I'm moving on the object layer. So this is based on OCSS. So you're gonna want to put visual patterns that are used repeatedly in a project, so I'll explain that later on. And this object layer can be categorized into three more layers. So the first is the component layer. You're gonna want to put your buttons, your inputs, your tabs, your labels, or your titles, anything that repeats itself over and over again. I put more than three times, but you can say more than four times. It's really up to you. And if possible your components should have minimum styling. So don't try to set a particular width for your button, because in another page you're gonna want to, I don't know, you're gonna want to pull the button wider or maybe something else, and you're not gonna have that flexibility if you put a set width. And also try to not avoid setting a color for your component if possible, but if it's set, I guess you could include it. And the prefix is dot c hyphen. Sorry, my rectangle is a little off. Okay, and then the second layer for your object layer is the project layer. And these are patterns that are unique to a certain project. So beside from your main website, you might have another blog, maybe like a blog for your company, or if you're running a e-commerce website, you might have a payment page that has a different button styling than your main EC website or something. So if you have a unique different project, that is, the style is deviating from your main project, then you want to put it inside the project layer. And the prefix starts with dot p hyphen. And lastly, you have your utility layer and classes in the utility layer are used to style slight changes in styles that cannot or should not be solved by component or project layers. So for example, if you have a button and you want to move it down by 10 pixels, you don't want to put it in your component, right? Because it's gonna affect your whole website. Your whole website is gonna have buttons with your 10 pixels button. So in that case, you can create a utility class. So for example, if you want to move your button down by 10 pixels, so margin top 10 pixels, then you want to make a class dot u m t 10, margin top 10 pixels, and you can use that as your fallback, I guess. And for flocks, we name our selectors by using Ben. If you don't know Ben, I'm sorry, but I probably don't have time to go through Ben, so please Google it. But it's basically using block element modifier. So if you have a block, underscore it and link it to an element and hyphen, hyphen modifier, yes. And if it's possible, try not to use a selector that's too long. So for example, don't have a block element element. Don't have a block element modifier and modifier. That's usually too long and it gets your code really messy, so try to keep it short, especially with your prefixes. And this is just another quick thing, but if you're gonna have states, so if your button is active, if your button is disabled, you're going to want to have a prefix dot is, so dot is active, or dot is disabled. And this isn't uncommon, so it shouldn't be anything new to a lot of you. And just one caveat, make sure not to put any styling onto the states, but make sure to combine it with a component. So you don't want to have dot is active, brackets, something inside. You want to combine it with a button or you want to combine it with something else. Okay, so by now, I hope you're all thinking, okay, like block sounds okay, but I don't really know where to start and I don't know when to start and I'm really scared because my CSS is like huge, I don't want to start. So I think I'm going to start sharing my refactoring experience. Yes, so where to start? I know this sounds really terrifying, but trust me, this is the best way. So first, if you want to refactor your CSS, just print out every single page of your website. And this sounds horrific, but do it because it's actually shorter. It's actually the shortcut. So print out every single page of your website and then you want to cut out each object or what you want to create as a component. And you want to find a name and a layer for it. And trust me, if you have a teammate, you want to go through this with your teammate because it's really amazing how your teammate will never agree with you. So it's like, no, I think this is going to be in the component and then your teammate will be like, no, obviously it's in the, I don't know, project layer or something. So you're going to consult your teammates about what name and what layer to put it in. Yes. Oh, sorry, there was meant to be a picture here, but never mind. And then third, after that, I actually categorized every object onto a spreadsheet. So I had my objects, I had about 60 objects and I placed them all on a spreadsheet, but this was a really terrible mistake because I never had the flexibility to move it around and it was like a nightmare. You don't want to scroll through your spreadsheets. So I recommend you stick it up on the wall. So if you have a huge wall that you can work with, put one of your cutout components on to stick it onto the wall and make sure you have categories. So make sure you place each object and stick it up on the wall. And then you can see, okay, I've got this much components to work through. It's a lot, but it seems manageable, right? So you can see what you're going to go through after this. And then after this, it's really easy. Make each object a task. If you use Trello, just put it up at the task on Trello or if you use something else, yeah, just assign yourself a task and just run through all of them. Yeah, usually you can get through maybe three to four objects a day, but then when you get used to it, you can get through more. And you can take out every object that you've done from the wall and make sure you make each object a pull request or a merge request if you skip lab. And yeah, make sure to get it checked. Yes, and lastly, I'm going to talk about some problems with Fox. So even speaking about Fox, I do feel like there's a lot of things that can be made better. And the first thing is that Fox itself is quite complicated. Some people don't really know where to start. And for example, if someone's new coming in, maybe they don't know it's Fox, and you've created this whole maze of CSS and they might not want to cooperate with you. So sometimes it's hard to maintain it, especially your naming conventions and also where you want to put your new classes. Yep. So it shouldn't go into the component layer or the project layer. Yeah, maybe someone's like, okay, who cares? Like, I'll just put it anywhere. And that destroys everything. So it is actually a bit complicated. So make sure your newcomers, you have documents prepared for your newcomers so that they can catch up with everything you've done. And third, if you're doing, if you're just carrying out a small project, it's not suitable because it's just too complicated. And yeah, it's not worth the energy. So if you have a huge project, yeah, maybe like start using it, but if not forget about it, maybe some other day. Yep, that's it. Thank you so much. And you can find me on these places and have a great night. If you have some, any questions, feel free to consult me or you can just use Google because they might have better information. Yep, that's all. Thank you. Any questions for Ayaka? I mean, we have five minutes, if not, yeah. Yeah, I think the rain, it's just... But I have a question though. Oh, okay. So let's say, so if I have a huge code base of CSS, what would be the easiest and simplest way to have flocks in committed? It's still gonna be a long process. So as you said, you have to print out everything. Yes, I find that that's the easiest way. But actually it reduces your CSS a lot. It reduces it a lot. So I've heard stories where they had 20,000 lines of CSS and it became 9,000. So it does help if you have a huge amount of CSS. If not, just write CSS as it is. It's not gonna change your web speed, your performance a lot, but if you do have a huge CSS as well. Before and after you have to basically test it and make sure that everything looks all right and the same as before. Yes, but, yeah, so that's the huge problem. But usually you're going through your tasks one by one. So you're changing objects one by one. So it shouldn't be... You shouldn't have many problems, but yeah. Because CSS is cascading and then change something and somewhere else in the universe gets changed. Yes, exactly. So that's why, yeah, yeah. If you're going to change it, dump your old CSS. Like don't even think of starting with your old CSS. Just dump it, like everything. Like don't use it any of it. Maybe except for your default CSS. So start with a fresh. Yes, start with a fresh page. So yes, it's going to take a lot of time and you start feeling bad because everyone's like, you guys haven't done anything. The website hasn't changed. You're taking like three months, four months, but it takes a lot of time. At first our team said we're going to do this in one month. And then after one month we're like, maybe this time it's going to take a bit more time. So give yourself some time and cheer up your teammates because they're going to feel the mental stress there. So... But after you're done, you're going to feel like, oh my God, CSS is so much better now. And it's easier to change, to create changes, make changes after you've structured your CSS, organized your CSS. Any more questions? Oh, thank you. We're going to have a discussion. I'm just curious about our programming background. So there's such thing as an automated unit test for CSS. Because when you change the CSS, something, the color or brand color will change. Are there some kind of automated test for CSS or based on human set? I think in terms of grammar, we have automated tests. And also I talked about unused CSS, but there's also tests for unused CSS. But in terms of checking whether the website still remains the same style, I don't think... I think you just have to look by eye, check by eye. Yeah. Yeah, there are some ways that people actually take screenshots of everything. Yes, there we go. And then you just run an automated test after you push out a request. Then that request will run through that page. Oh, that's cool. It takes a lot of time. OK. That's cool, guys. Oh, that's cool, though. You have to know what's the testing framework so that everyone can... Every Facebook has one for you. This Facebook has one called Huxley. Huxley. Huxley, I think. But I've never used it. There's a new company that does that. Yeah, I mean, it doesn't have to become exactly the same like to one pixel, does it? It's my question. Well, I'm not sure. The proper part of the problem with it is that if you do an image test, right, then literally every pixel counts. Right, exactly. So if you have like a one pixel difference, it's going to... Right, yeah, exactly what you said. Is there an English language reference for Fox or not? That's a great question. No. I mean, I just looked at my phone and everything was Japanese. Yes, everything is Japanese. Where will we go next? You might want to come to me. So I can't use a translation. I was thinking of issuing a pull request because there's an issue up there saying there's no English translation. I'll do it someday if you give me some time. Yeah, but you can talk to the developer. His name is H-I-L-O-K-I Hiroki. And I'm pretty sure he speaks English. So, yeah. OK, cool. So without any more questions, thank you. Yes, thank you. Thank you.