 So today I'm going to talk about CSS Architecture, a robust, flexible, and scalable CSS for enterprise projects. Before I begin, I want to ask how many of you guys consider themselves architects or CSS architects? I'm going to start with defining the world. What's the word architecture, first of all? I found this definition online. Architecture is a systematic arrangement of components. I don't know who wrote that, so it's an unknown, but I like the definition. Before I start my talk, I want to give credit to these three guys, Harry Roberts. He's the guy who executed these methodologies and documents that have been online for quite a while. He's also the author of CSS Wizardry, if you guys are aware of that. Jonathan Snook, I'll speak about him later. He introduced SMACTS, the book for scalable CSS. I'll talk about that later on in my slide. And Nicole Solidvan, who introduced the concept of object-oriented CSS. So I'm going to start with CSS Architects Do Mistakes, and all of us feel guilty about it. We encounter a lot of insufficient documentation, lack of structure, project knowledge, poor handoffs, and new styles at the bottom of the global style sheet. We all do that. How many of you don't do that? Okay, cool. All right. As I mentioned, this is the SMACTS. I think it came out back in 2012. It's pronounced SMACTS, S-M-A-H-C-S-S. Jonathan Snook is the one who introduced the concept of structuring CSS into various categories. And these categories later on are called CSS layers. We'll talk about that later. Understanding the purpose of CSS layers adds a lot of meaning to the style that you write. We start with the default layers. I'm going to just jump in right into it. The default layers are broken into generic elements, objects, components, utilities, tools, settings, and JavaScript hooks. I'll go briefly into each of these categories, and we'll take questions later. So we'll break it down. Starting with generic. Generic is, in fact, the first layer that generates CSS. Some of these files, the generic can be considered as a box sizing, the normalized CSS. All the resets and all the shared styles will fall under the generic category. An example of that, declaring the HTML box sizing, border box, this is considered generic. Moving on to elements. Elements are actually refining the default HTML element styles. Some of the elements we know are headings, elements, headings, images, page, and tables. An example of that, an image is an element in the DOM, and you can declare these values of maximum width, 100%, and vertical or line middle. This is considered an element. Next are objects, and objects are pretty much cosmetic-free design patterns, such as the media object. The media object was introduced with the object-oriented CSS back in 2012. Any of you know what the media object is? Okay, cool. I'll show you an example later, but objects can be considered as a block box layout, the media object, and a wrapper. An example of that, this is what we call a media. It's a very standard object we use in. You will see it in most of the blocks online these days. The way we declare it is all referred to an object, dash media, and the media, if you're using SAS or if you're familiar with pre-processing CSS, we use the include mixing, clear fix, and we display block. Later on, we will declare the elements within this object. The elements here we can see is an image, an image and a body. In this example, we make it simple. So we have an image. We declare the left, margin, right, and the image as a display block, and the all media body. The all media body has a display block, overflow, hood, and so on. Moving on to components. Components are actually project-specific UI components that contain objects and elements. This is where all your work will be. When you're structuring all your CSS, when you're building your CSS architecture, you only need to add new CSS components. Everything else needs to be set and there for you. You don't have to touch it. All the work will happen in the components. An example of these components can be bullets, buttons, fonts, and codes. A button can be a component. An example of that is we can declare it as a C dash component and a button, and then we add these values. If you want to declare a modifier button to the main button, we call it a C button primary. And then we add a background if there's any background, and then we attach it to a brand color function. And hover and focus, and so on. Next is utilities, helper classes that has the ability to override CSS. These classes can be set by you and you can set whatever helper classes that you need to use in your project. You don't have to add any helpers that you don't want to use in this project. And these can also be adjusted according to the project that you're working on. So utilities, we have a clear fix, headings, the standard files that you need to create, headings, hide, spacing, width, and so on. The utility class fix can include just a mix in of include, clear fix, and the utility hidden or invincible will include an invincible mix in. Utilities classes can put spacing values into elements. We can generate a set of classes like these, for example. And these values will be set by you. You can only set whatever works to that specific project. And these values can be taken from one file. So you set all your values in one file and then everything will be captured from there. The same applies to grid systems. And the naming can be pretty much whatever works to you. Either it can be a fraction-like format or a spoken-word format like utility 4 of 16, which is 4 out of 16 grid, or U-7 forward slash 12. Next will be tools, predefined mixings and functions. These works only with preprocessors. So if you're not familiar, you don't need that to be there. So we include a functions, mixings, and responsive if we are doing a responsive websites and declaring the width. One of my favorite mixings I use all the time is the mix-in vendor. And what it does is I'll only need to use one line and then I'll add all the prefixes that I need to be generated in my CSS file. This is just an old practice that I use. An example of that will be the include vendor. I think I like the simplicity that I just need to include just one line. Yeah, sometimes it depends on the project itself, whether I want to support older browsers. Yeah, but you just change all the prefixes. Correct, yeah. So it's complete rather than code? Correct, yeah, yeah. It's all done in the configuration. Yeah, that's how you use them eventually. Settings is where you pretty much set all these values and all these values that will be read by all these files. So in the settings, we have a config, core, global, and responsive. The global will be, if you're working on a big project and it has to be localized to different markets, the core will be the market. So if you are launching your product to the Hong Kong market and the Hong Kong market has a different color schema, then you only need to add one file of setting core or settings Hong Kong and then you just change all the values one shot. And that's it. Everything else will be rendered. These settings, an example of these will be setting the global font, radius, and transitions. The brand color, secondary color, all the text color, and so on. JavaScript hooks is something, it's a good practice that I use. It doesn't have to do anything with CSS, but I thought I will probably mention it because it's a good practice to add a JS dash to the classes that you don't need to. Or you want to tell your developers that don't style these with this class because it will be used by JavaScript. So you don't need to add any CSS to it. It's just a good practice and I feel like it's worth mentioning. An example of that, a JS model, white, black, a button blinking and form validation. And I forgot to mention that CSS architecture is not really a framework, but I would like to call it a style guide. Because there's a lot of frameworks in the market and they all have predefined styles that they are there. And you just use them or you override them eventually which creates a lot of unneeded codes. So this, by setting up a good architecture or a good style guide at the very beginning of the project, will save you a lot of time and a lot of effort to maintain your code. So what are the benefits if we follow this architecture? We will have clearly a more understandable structure. We can scale at ease, long-term maintainability, smoother project handoffs and easier collaborations. Existing style guides in the market now are IT, CSS. This one is created by Harry Roberts. He's still trying to spread that awareness about this structure. He uses the same layers as I mentioned earlier. Settings, tools, generic elements, objects, components and trumps. Trumps is a new layer meant for adding new functionality to your project. Surprisingly there's no source code in GitHub for this. But he has a long blog post about explaining how settings, tools and all these layers work and how you can use them in your project. Next one is the InWit CSS which you can find it on GitHub. And I personally use it. It uses the similar, again it's by Harry Roberts and it uses the same layers that I mentioned earlier. I'll probably show you an example later of how the folder structures structure properly. And I can't pronounce this but I love it, the CSS. This guy, he took the idea from InWit CSS from Harry and then he just reused it and then he added his own naming convention to it. It's pretty much similar, it's using the same methodology which is a good practice. Before I go to useful reads I'll probably show you how I downloaded InWit CSS before I came here. And maybe I'll show you how the folder structure works. So InWit CSS, now I think it's not just maintained by Harry. A lot of guys already realize how important this and how big it can go. So I think there are about five guys now maintaining the project. Again this is where, maybe I'll just add on. So in InWit itself there's no documentation in the GitHub page but you'll find a lot of documentation within these files themselves. Harry put a lot of effort to document within the file. So when you open the file you understand exactly what is this file is going to be used for and where you can change the values and where you can't. These are again the generic, the resets and so on. The most interesting one would be the configs where you set all these values. So you just need to use them once here and it will be used across all your site. The components, you might find it empty because the components are the components you use for your own project. So you don't have to get components from elsewhere. It really depends on the project that you work on and what components you really need on your website. So all these components will be broken down into different files. Again I used InWit in one of my projects before and I find it really easy to scale up to different markets. Every time we start a new project a lot of the clients, if you work with clients directly, a lot of the clients will tell you, oh we will start, we will just start first, right? We'll just start, launch the product in Singapore or Malaysia and then we'll see how it goes. But you really don't know what's the future plan is. The product will work, will kick off nicely, will kick off and then you need to scale up. And if you are not using a solid architecture you will have a lot of difficult time and then you will always have to go through the revamps which you are all aware of. We revamp, revamp, revamp and it's just a loop in this loop. So what I like about setting up this strong structure is you can scale very easily. If you have to go to a different market, let it be and then you already have this fundamental set and you just need to pretty much work on these components. Yeah, that should be it. You can check it out in GitHub in CSS and then you'll find more details about it. Some useful reads, I encourage you to go and read it. CSS guidelines by Harry Roberts. It's a simple guidelines of how to use, how to write clean CSS codes in your projects and how to keep it very clean so you can hand it over to newcomers who come in and join the project who have no clue how to work on certain files. And it reduces a lot of these moments where you just go into the CSS file and then you just add lines at the very bottom of the file, which is a very bad practice. Second is the Idiomatic CSS by Nicholas Calico. It's a GitHub page. I'll share the slides maybe later. And yeah, that's about it. My name is Giz, and thank you for listening. Let's do this. Here, what's chocolate? Chris, for chocolate and you, you've got questions. No, I'll hurt people if I have to write chocolate. Oh, you're so shy. Don't be shy. Thank you. Say, look, he's happy. He's got chocolate. You too can be happy. Oh, anyway, this is my CSS mascot. It is a Unicorn Kitten or Unikitty. And he's very angry because everybody simply uses important all the time. So every time I want to use important, you think of my angry Unikitty and stop it. Anyway, next talk is also very cool. Next talk is a project by Aisha about, but it's very cool. So I'm not going to spoil it.