{"id":2441,"date":"2016-03-28T13:51:01","date_gmt":"2016-03-28T13:51:01","guid":{"rendered":"http:\/\/www.ckl.io\/?p=2441"},"modified":"2022-07-01T17:59:40","modified_gmt":"2022-07-01T17:59:40","slug":"css-architecture-first-steps","status":"publish","type":"post","link":"https:\/\/cheesecakelabs.com\/blog\/css-architecture-first-steps\/","title":{"rendered":"CSS Architecture: First steps"},"content":{"rendered":"

CSS was designed to be a very simple and intuitive language. Its basic purpose is to define selectors to target HTML elements and apply attributes to them. Easy to grasp and start applying. When working on large and complex projects, though, some CSS features might be a little trickier to deal with.<\/p>\n

Its cascading<\/a> feature, for example, allows properties to be overridden by other selectors according to its order on the sheet or by selector specificity<\/a>. Also, elements inherit<\/a> properties from their parents on the DOM. Without proper organization, this can quickly get out of hand and messy. That’s where an architecture comes to help.<\/p>\n

<\/p>\n

What is a CSS Architecture?<\/h2>\n

A CSS architecture brings reasoning to CSS authoring. Imagine it as a set of guidelines and best practices to help developers write code that’s maintainable<\/strong>, flexible to scale<\/strong> and more reusable<\/strong>. We achieve that by applying a modular approach<\/strong>, promoting organization<\/strong> and conveying meaning<\/strong> to our codebase. We\u2019ll see how to apply these principles with 3 basic steps.<\/p>\n

Modularity<\/strong> is a core concept. Not only on a code level, but also on a design one. Digital products have evolved a lot in the past years, due to the rise of new devices and the responsive web. Complexity has changed. We, as developers and designers, have to support this new scenario. Designing pages is no longer the best approach; we should build design systems<\/a>. Page-based CSS won’t suit our needs on building flexible and scalable products. Working with reusable components is the way to go.<\/p>\n

On a CSS architecture, modularity can be applied on several levels. The three basic steps to start structuring your CSS that way are by:<\/p>\n

    \n
  1. breaking the code into smaller chunks and separating them by scope;<\/li>\n
  2. coding components in a independent and encapsulated manner;<\/li>\n
  3. naming CSS selectors according to their purpose and relationship with each other.<\/li>\n<\/ol>\n

    Getting started<\/h2>\n

    1. Separate and categorize your code<\/h3>\n

    To keep the architecture modular, it\u2019s important to break the code into smaller parts. Multiple files make the code easier to read, navigate and track. To do that, a CSS preprocessor \u2013 such as Sass<\/a>, LESS<\/a> or Stylus<\/a> \u2013 or a post-processor \u2013 such as PostCSS<\/a> \u2013 is the way to go. Preprocessors enhance the capabilities of CSS authoring, introducing new features such as variables, mixins and much more<\/a>. To work with separate files, your code will be divided into partials<\/a> and imported<\/a> on a main.scss<\/code> file, that will compile everything into a single .css<\/code> file.<\/p>\n

    \"main-scss\"
    Example of a main.scss<\/code> file. (Spoiler alert: it’s already categorized :P)<\/figcaption><\/figure>\n

    Now it’s time to categorize each code block according to its scope on the project. One of the first methodologies out there to introduce selector categorization was SMACSS<\/a>. The layers proposed by SMACSS are Base<\/strong>, Layout<\/strong>, Module<\/strong>, State<\/strong> and Theme<\/strong>. ITCSS<\/a> expanded this concept, introducing other layers, such as Settings<\/strong> and Trumps<\/strong>. MVCSS has a similar approach, but with different naming conventions<\/a>.<\/p>\n

    \"ITCSS
    ITCSS layer convention.
    https:\/\/speakerdeck.com\/dafed\/managing-css-projects-with-itcss?slide=49<\/a><\/figcaption><\/figure>\n

    You don’t need to follow these methodologies strictly. Learn the examples and figure what better fits your project. In my opinion, separating your architecture into Settings<\/strong>, Base<\/strong>, Layout<\/strong> and Components<\/strong> is a good start. Settings<\/strong> is where your configuration files, such as variables (colors, sizing, typography definitions…) and helpers (functions, mixins\u2026) will be stored. The Base<\/strong> layer will contain your reset<\/a> and unclassed HTML rules \u2013 the way a default <a><\/code> or <input><\/code> should look like, for example. Layout<\/strong> stores the structural classes that hold components on the page \u2013 grids and containers, for example. And lastly, Components<\/strong>: the core of CSS architectures and design systems.<\/p>\n

    2. Define your Components<\/h3>\n

    I consider components the core of a CSS architecture because that’s where most of the code will live. They are the reusable visual patterns that compose a user interface \u2013 buttons, accordions or modals, for example.<\/p>\n

    \"A
    A button component.<\/figcaption><\/figure>\n

    Each component should be encapsulated on its own file. For consistency reasons, it’s a good practice to use the same name for the file and main selector.<\/p>\n

    \"A
    A button.scss<\/code> file.<\/figcaption><\/figure>\n

    Some components aren’t as straightforward as a button. Some are more complex, composed of inner elements. Take this blog post component, for example. It has a thumbnail<\/strong>, a title<\/strong>, an excerpt<\/strong> and a link<\/strong>.<\/p>\n

    \"A
    A blog post component<\/figcaption><\/figure>\n

    Sometimes, when defining components, you’ll be asking yourself what should be a standalone component or part of a larger block. To answer that, search your product or website for repeating patterns. If it is used on different contexts, abstract it to a standalone component. On the blog post example, the .link<\/code> element is a separate component, because it is also used on other parts of the website. The other elements are specific to the blog post. Let’s see how to handle this relationship with selector names.<\/p>\n

    3. Apply a naming convention<\/h3>\n

    Remember: we want our architecture to convey meaning<\/strong> and promote organization<\/strong>. Using a class naming convention in our components will help us achieve that. A pattern such as BEM<\/a> (Block, Element, Modifier) will clarify the intention and relationship between a component (the Block) and its elements, as well as reinforce predictability when compared with other components. The idea behind BEM is to name things according to this structure:<\/p>\n