Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Styling with classes vs styling with CSS

+8
−1

I've noticed that a lot of sites have something like this going on:

<div class="has-margin-0 has-padding-4">
    <div>...</div>
    <div>...</div>
    ...
</div>
.has-margin-0 {
    margin: 0;
}
.has-padding-4 {
    padding: 4px;
}

I'm a beginner who's self taught / internet searched most of their HTML and CSS knowledge. Currently I use human readable class names and style those instead of this weird (to me) method of moving the styling to classes. However, the "style by classes" method seems to be pretty popular for some reason, and I'd like to know why.

What are the pros and cons of using that method?

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

1 answer

+6
−0

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.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

General comments (4 comments)

Sign up to answer this question »