Організація класів у HTML та їх стилізація: огляд підходів OOCSS, BEM, Atomic CSS і SMACSS

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Як часто ви стикаєтесь з плутаниною у стилях ? Коли CSS перетворюється на «спагетті-код», будь-які зміни викликають конфлікти, а масштабування проєктів стає кошмаром. Щоб уникнути таких ситуацій, важливо не лише правильно писати CSS, але й використовувати структуровані підходи до організації HTML-класів та їх стилізації.

У цій статті я поділюсь власними спостереженнями та порівняю кілька популярних методологій: OOCSS, BEM, SMACSS та Atomic CSS. Окрім того, я запропоную ідею використання змішаної архітектури, яка може бути практичним рішенням для багатьох проєктів.

Чому це важливо прочитати:

• Зменшення складності CSS: уникнення дублювання стилів та створення «порожніх» класів.
• Легкість масштабування: проєкт залишається структурованим навіть після додавання нових компонентів.
• Уникнення конфліктів: чітка модульна організація знижує ймовірність накладання стилів (вибірки CSS).

OOCSS

Об’єктно-орієнтований CSS (OOCSS) зосереджений на створенні гнучких та багаторазових компонентів, подібних до OOP. Основна ідея полягає в ізоляції та абстракції інтерфейсу на самодостатні блоки HTML та CSS, що дозволяє нам повторно використовувати код та уникати повторень (іншими словами, DRY).

<div class="card">
  <h3 class="card-title">Заголовок</h3>
  <p class="card-description">Короткий опис</p>
</div>

Клас card можна використовувати повторно для різних компонентів, що відповідає OOCSS-принципам.

BEM

BEM (Блок, Елемент, Модифікатор) — це специфічне застосування принципів OOCSS. Хоча я не повністю задоволений цим методом, його структура може бути корисною. Однак BEM може бути громіздким та складним у використанні: блоки — це кореневі класи, елементи — це частини блоків, а модифікатори — це варіації представлення.

<div class="button button--primary">
  <span class="button__icon"></span>
  <span class="button__text">Надіслати</span>
</div>

Назви класів у BEM чітко визначають, до якого блоку належить елемент.

Atomic CSS

Atomic CSS зосереджений на створенні багатьох невеликих допоміжних класів для використання в HTML, відомих як «помічники». Хоча він схожий на OOCSS, Atomic CSS заохочує розділення стилів на найменші компоненти, що робить його більш екстремальним методом. Це дозволяє використовувати стилі з максимальною гнучкістю.

<div class="p-4 bg-light text-center">
  Atomic CSS
</div>

SMACSS (Scalable and Modular Architecture for CSS)

SMACSS пропонує організовувати CSS за категоріями — базові, компоненти, макети, модулі тощо. Це дозволяє чітко структурувати код.

• Сильні сторони: Легко уникнути конфліктів стилів. Чіткий поділ на різні рівні.
• Слабкі сторони: Потреба в глибшому розумінні проєкту з самого початку.

Категорій у SMACSS:

• Базові стилі
• Макет
• Модуль

OOCSS, BEM, SMACSS та Atomic CSS мають свої переваги та недоліки. Хоча BEM може бути громіздким, його структура корисна. SMACSS та OOCSS допомагають уникнути спагеті-коду. Кожен із цих підходів може покращити вашу архітектуру CSS у різних проектах, тому варто експериментувати та знаходити найбільш підходящий для ваших потреб.

Реальна практика — комбінування підходів

У реальних умовах часто доводиться поєднувати різні методи. Наприклад:

• Використовувати SMACSS для загальної архітектури, забезпечуючи чітку модульність.
• Інтегрувати BEM для ключових структурних компонентів.
• Додавати Atomic CSS класами для дрібних стилізацій (поля, відступи).

Такий мікс допомагає створити баланс між гнучкістю та організацією коду.

Висновок

Моє ідеальне бачення архітектури — це мікс. Якщо ви бачите, що фрагмент коду можна використовувати повторно, варто базувати його на SMACSS, використовуючи Atomic CSS для деталізації стилізації. BEM можна використовувати для структурних розділів, а вміст можна деталізувати відповідно до вкладеності, наприклад, використовуючи OOCSS для повторюваних елементів.

Нагадування

Цей текст є виключно моїми думками та спостереженнями, заснованими на практичному досвіді. Змішаний підхід, який я описав, здається мені найбільш логічним і корисним для організації CSS-архітектури, особливо під час роботи над проєктами з великим обсягом кодової бази.

Однак важливо пам’ятати, що ефективність будь-якої методології залежить від контексту проєкту. Найкраще організовувати архітектуру стилів, коли ви працюєте над новим проєктом «з нуля». У цьому випадку у вас є більше свободи для експериментів і структуризації коду. Впроваджувати будь-які методології у проєкти, які вже мають свою складну структуру, може бути значно важче — особливо якщо CSS вже перетворився на «спагеті-код».

Тому моя порада: завжди ретельно аналізуйте вимоги вашого проєкту та підходьте до вибору методології свідомо. Ваша ціль — створити архітектуру, яку буде легко підтримувати й масштабувати в довгостроковій перспективі.

LinkedIn: www.linkedin.com/...​leksii-serdiuk-381113167