This styling method is called "atomic classes".

The goal of those is to prevent writing repetitive and badly maintainable CSS. For example, we might want to have primary colored variants of buttons and notices. In non-atomic CSS we'd write something like this:

.button {}
.button.btn-primary {
    background-color: #314159;
}

.notice {}
.notice.notice-primary {
    background-color: #314159;
}

And if we had more components where the background might become primary colored, we'd have to repeat the rule even more. This violates the principle "DRY: Don't repeat yourself" and creates maintenance issues, because you might miss some of the situations if you were to change the primary color.

Granted, the maintainability isn't that much of an issue anymore if you use modern CSS3 variables, but there is still an DRY issue.

On the other hand, if you use atomic CSS, you can simplify the code to:

.button {}
.notice {}

.bg-primary {
    background-color: #314159;
}

Now we have a helper class (.bg-primary), that can be used everywhere where you want a primary color background. Without writing any further line of CSS. Even on our nice widget component, that – until now – didn't knew anything of primary backgrounds.

Furthermore, atomic classes allow you to simply change the styling of a component at the place where it is defined: in the HTML code for it. If you want to change the button color, just replace class="button bg-primary" with class="button bg-grey" and voilà.

While some might (and do) argue, that atomic CSS is, like inline CSS via style="", the worst crime against semantic HTML since the invention of <div>, there are some objective advantages over inlince CSS:

• Specifity. Inline CSS has a very high specifity and is hardly overriden by CSS, unless you use !important. Atomic CSS OTOH has a very low specifity, because it's only basing on classes for element selection. This allows you to easily override it via most other selectors (attributes, IDs, selector chains, ...)
• Flexibility. Inline CSS isn't very flexible. For example it isn't possible to react to hover/active/focus state or to use media queries. All of this is possible with atomic CSS, though.

Atomic CSS is also great for templating stuff and making "mockups", because you can create almost any style you want with just a few classes and without writing any CSS. If you were to use components, you'd have to write a lot of CSS only for that mocked up new component, which doesn't happen with Atomic CSS.

However, atomic CSS (at least when applied strictly) doesn't allow for reusable components. If you want a button, you'll always have to add .bg-primary .c-white .radius-3. While this might be okay for a button, it stops being trivial for complexer components (e.g. widgets or grids).

To mitigate that issue, many framework developers (including for example Bootstrap or Co-Design, the framework used by this very site) use a mix of classical component-based and atomic CSS. They provide often-used components (for example buttons, alerts or cards) and allow users to override the default styles with the atomic helper classes.

posted about 4 years ago

CC BY-SA 4.0

luap42‭ staff

471 reputation 2 7 54 2