Maintainable CSS

Before we start styling, I would like to talk briefly about the importance of maintainability in CSS. Despite the fact that CSS is a declarative language, it requires no less diligence than any other code in general. When browsing a public repository, such as GitHub, you can still find plenty of projects where all the styles are put in a single file that is full of code smells (https://csswizardry.com/2012/11/code-smells-in-css/) and has no consistency in class naming.

Well, it will not be much of a problem at the beginning, but CSS as any other code tends to grow. Eventually, you will end up with thousands of lines of rotting code often written by different people.

Then, you have to fix the UI element appearance, but you realize that dozens of existing CSS declarations across the cascade impact this element. You change one, and styles break unpredictably on other elements. So, you will likely decide to add your own rules overriding existing styles. After that, you may find out that some of the existing rules have a higher specificity, and you will have to use brute force through the cascade; every time it is going to be worse.

To avoid this maintainability problem, we have to break the entire application UI into components and design the CSS code so as to keep them reusable, portable, and conflict free; the following heuristics may come in handy:

• Split the whole CSS code into modules that represent components, layouts, and states
• Always use classes for styling (not IDs or attributes)
• Avoid qualified selectors (selectors with tags such as nav, ul, li, and h2)
• Avoid location dependency (long selectors such as .foo, .bar, .baz, and article)
• Keep selectors short
• Do not use !important reactively

There are different methodologies that help to improve CSS maintainability. Probably, the most popular approach is Blocks Elements Modifiers (BEM). It introduces a surprisingly simple, but powerful concept (https://en.bem.info/methodology/key-concepts/). It describes a pattern for class names that encourages readability and portability. I believe that the best way to explain it is by an example. Let's say we have a component representing a blog post:

<article class="post"> 
   <h2 class="post__title">Star Wars: The Last Jedi's red font is a 
    cause for concern/h2> 
   <time datetime="2017-01-23 06:00" class="post__time">Jan 23, 2017</time> 
</article> 

In BEM terminology, this markup represents a block that we can define with a class name post. The block has two elements--post__title and post_time. Elements are integral parts of a block; you cannot use them out of the parent block context.

Now imagine that we have to highlight one post of the list. So, we add a post--sponsored modifier to the block's classes:

<article class="post post--sponsored"> 
.... 
</article> 

At first, class names containing double dashes and underscores may make you dizzy, but after a while you will get used to it. The BEM naming convention helps developers remarkably by showing indention. So when reading your own or somebody else's code, you can quickly figure out by its name what the purpose of a class is.

In addition to the BEM naming convention, we will use a few ideas from the Pragmatic CSS styleguide (https://github.com/dsheiko/pcss). We will give names prefixed with is- and has- to the classes representing global states (for example, is-hidden and has-error); we will prefix layout-related classes with l- (for example, l-app). Finally, we will amalgamate all CSS files in two folders (Component and Base).