<p>Writing CSS is hard. It’s one thing a lot of us can agree on. There are a lot of things to grapple with and as a codebase grows, it becomes harder to maintain. A common problem with this is <strong>overrides</strong>, i.e when the properties of a CSS class that is defined somewhere in a file get replaced by the properties of another CSS class defined somewhere else with the same [class] name - either on the same or a different file.</p>
<p>When setting up a new codebase, one of the challenges I face is choosing a maintainable CSS structure. It has to be a structure that is easy to understand, follow, test, and debug. Oh, it also has to be easily searchable. There is always the temptation to veer off the current CSS structure on a codebase and write something quick that solves the problem, especially with time-bound features. Taking the time to map out a list of things to consider as I build has saved me a considerable amount of time and debugging energy.</p>
<p>In this post, I will share some tips for writing consistent and clean CSS that I have picked up along the way.</p>
<h3>Identify base selectors</h3>
<p>Base selectors target HTML elements in their tag form, e.g, p, a, h1, h2, body…etc. Once I identify the base selectors, I do a conventional CSS reset which helps to manage browser inconsistencies. (Not all browsers share the same default styles, so it makes sense to do a reset to enable us to start on a clean slate). Next, I set the default styles for these elements. For me, this also includes setting styles for the typography.</p>
<h3>Identify and create a base layout</h3>
<p>CSS layouts get mixed up sometimes with components. Although they both share a similar function of grouping related things, I see layout as more of a container that houses components to give pages a specific shape. There are several ways to imagine a layout based on the page’s design. After defining the layout, I move on to naming.</p>
<h3>Naming conventions</h3>
<p>Naming in programming is difficult and one of the most important things we have to do as we build software applications.  Naming allows us to recognize features with similar functions and group them accordingly. It also allows for the separation of concerns.</p>
<p>There are several CSS naming conventions like this and <a href="https://groups.google.com/g/sass-lang/c/F9MnjqSCaPs/m/H6R7rGR7E-cJ">this</a> The BEM (Block, Element, Modifier) convention is one that I find useful for naming classes, especially when working with components. It also provides structure and is easy to understand.</p>
<ul>
<li>The <strong>block</strong> in the BEM is for components that are abstracted at their base level. Think of it as something that can act as a standalone, i.e a button, header, or modal.</li>
<li>The <strong>element</strong> is dependent on the block. It has no meaning without the block (parent), e.g, the links in a navbar</li>
<li>The <strong>modifier</strong> is used to change the state of either the block or element, such as its appearance or behaviour.</li>
<li>For BEM naming, I prefer to use a <strong>double hyphen</strong> to separate the block and the modifier, an underscore to separate the block and element. For a class that combines all three, I use an <strong>underscore</strong> to separate the block and element, and then, <strong>double hyphen</strong> to separate the element and modifier. Just like the example below:</li>
</ul>
<pre><code class="language-css">/**** block acting as a standalone ***/
    .header {
        border: none;
        padding: 15px 30px;
        text-align: center;
        font-size: 16px;
        cursor: pointer;
        min-height: 50px;
    }
    /* block and a modifier combined */
    .header--lg {
        min-height: 80px;
    }
    /* block, element and modifier combined */
    .header__item--lg {
        font-size: 20px;
    }

</code></pre>
<h3>Thinking in components</h3>
<p>Thinking in components when writing CSS helps me identify patterns that can be abstracted. That is, it shows me parts of my CSS code that have been repeated and if I have to write a particular style more than once, it makes sense to bundle that repetition into a single class and reuse that class in different instances. This helps with reusability and less bulky code.</p>
<p>When thinking in components, naming classes is very key. I usually want to name classes in a way that is intuitive and reusable. For example, having a component class name like <code>.homepage-nav</code> is limiting and doesn’t describe the full functionality of the component. Renaming the above component to something like a <code>.nav</code> shifts it to a general component that is applicable in a different context.</p>
<p>Also, if I use CSS pre-processors, like LESS or SASS, I keep components in their separate files. For example, a <code>button</code> component is written in its <code>button.scss</code> file. This helps me to easily navigate my codebase, especially during debugging.</p>
<h3>The <code>!important</code> property</h3>
<p>I limit the use of this property to when I am 100% sure that I don’t want a property to be overwritten in a codebase. I try to minimize how often I use the property, especially when creating components that need to be overwritten at some point by modifiers.</p>
<h3>Spacing</h3>
<p>For readability purposes, I always add new CSS rules on a new line even if they are comma-separated.</p>
<pre><code class="language-css">.content,
.content-edit {
 
}

/**** vs ***/
.content, .content-edit {  
  
}
</code></pre>
<h3>Comments</h3>
<p>I use comments to specify the beginning and end of similar CSS rules. Helps for better navigation.</p>
<pre><code class="language-css">/************ Button   ***********/
.btn {
  …
}
/************ Button   ***********/
</code></pre>
<h3>Conclusion</h3>
<p>Writing good CSS is hard and requires us to be intentional about a lot of things. Having documented rules help teams working on or getting acquainted with a codebase navigate the codebase better. Rules can be flexible but always make sure that they are easily understood by stakeholders.</p>
<h3>Notes</h3>
<ol>
<li>Here are some resourcesI found helpful: <a href="https://anotheruiguy.gitbooks.io/sassintherealworld_book-i/content/aLittleUnderTheHood/naming.html">[1]</a>, <a href="https://groups.google.com/g/sass-lang/c/F9MnjqSCaPs/m/H6R7rGR7E-cJ">[2]</a>, <a href="http://getbem.com/introduction/">[3]</a></li>
</ol>
