Передрукував тут статтю, яка канула в Лету.
Багато девелоперів, навіть маючи за плечима не один успішно виконаний комерційний проект не залишають пошуки найкращого способу організації стилів в макеті. І більшість з них зупинилися на синтезі OOCSS. SMACSS. BEM і SASS. У цій статті ми не тільки поговоримо про те, що з себе представляє правильний CSS. союз OOCSS. SMACSS. BEM і SASS. але і розглянемо найбільш ефективну структуру організації файлів в макеті.
Для початку згадаємо, що з себе представляє кожна з трьох методологій об'єктно-орієнтованого CSS.
OOCSS + SCSS
Принцип OOCSS полягає в роздільному існуванні об'єкта і його модифікацій. Це потрібно для того, щоб ми могли помістити клон об'єкта в будь-яке місце на сайті без необхідності перебивати існуючі стилі.
Клон об'єкта через новий клас розширюється додатковими стилями (дизайном). Таким чином, в html документі до одного блоку присвоюється відразу кілька класів. Нанизування класів характерно для багатьох фреймворків, наприклад Bootstrap.
Однак множинність класів йде врозріз з принципами SMACSS. який рекомендує уникати повторень. Це один з головних принципів написання «чистого коду».
На допомогу приходить SASS. а саме директиви
@include і @extend. З їх допомогою до будь-якого блоку можна приєднувати додаткові стилі минаючи html.
За допомогою рядка
ми розширюємо класи blue і red стилями з класу button:.
При компіляції SCSS ми отримуємо такий запис в CSS:
Це повністю збігається з принципами OOCSS. які настійно рекомендує дотримуватися його творець Jonathan Snook. АЛЕ! Стилі для класу button також записуються в CSS. І в даному випадку абсолютно марно, вони нам не потрібні. Так дуже часто буває в макеті, коли базовий дизайн не застосовується.
В такому випадку краще скористатися директивою Placeholder Selectors (%). Placeholder записується в CSS ТІЛЬКИ! коли його викличуть:
Однак в такому випадку в скомпільованому CSS одні і ті ж стилі будуть повторюватися в кожному класі.
Те ж саме відбудеться і в разі використання директиви @mixin. Однак при використанні mixin ми отримуємо певну перевагу.
Змінні, визначені в mixin. можна змінити один раз і вони зміняться в усьому макеті відразу. Це економить масу часу і сил. Крім того, використовуючи миксин, можна в блоці змінювати значення змінних, якщо того вимагає дизайн (дивіться демо).
SASS дозволяє уникнути зайвих класів в макеті завдяки вкладеності. Однак іноді вкладеність грає з нами злий жарт і до блоку застосовується велика спадкування, типу
І тут настав час звернутися до методології BEM. розробленої компанією Yandex. Вона визначає принцип створення імен класів для елементів різного рівня і їх станів.
У статті ми будемо розглядати не оригінальний BEM, а версію Nicolas Gallagher. якої все вважають за краще користуватися, тому, що вона набагато прозоріше.
Якщо коротко, що вона з себе представляє правильний CSS на BEM.
.block - стиль для батьківського блоку
.block__element - стиль для вкладеного дочірнього блоку.
.blockmodifier - стиль стану блоку.
Можуть бути різні версії.
У дочірнього блоку може бути стиль стану:
У стилю стану може бути дочірній блок:
За відгуками девелоперів, її протестували, методологія BEM кілька потворна в написанні і заплутана в сфері застосування.
Наприклад, творець csswizardry.com Harry Roberts наводить приклад:
Нижня підкреслення говорить про приналежність h1 до дочірньому елементу. Однак Harry підкреслює, що не впевнений, чи завжди клас для h1 в даному випадку слід писати таким чином.
Але тим не менше він кілька разів повторює на сторінках своєї статті думка: неважливо, наскільки красивий виглядає технологія, головне, що вона працює!
Як би там не було, BEM прекрасно вирішує проблему з успадкуванням в SASS. І хоча б одним цим він може бути нам корисний, щоб написати правильний CSS.
У SASS ми пишемо:
У скомпільованому CSS виходить:
Sass 3.3+ BEM уможливлює наступну комбінацію:
У скомпільованому CSS виходить:
Спадкоємства кінець, генерується тільки один клас!
Організація файлової структури
А тепер поговоримо про організацію файлової структури макета на SASS. Вивчаючи досвід провідних зарубіжних девелоперів і їх макети, а також використовуючи власні скромні пізнання, мною був зроблений наступний висновок про оптимальну структуру макета:
Найчастіше це style.css, але тут в мені говорить звичка робити макети на html5 boilerplate. Основний файл макета, куди імпортуються всі інші його частини (див. Нижче)
Включає в себе normalize.css і стилі для базових елементів сайту: html, body, a, ul, li і так далі.
Якщо ви користуєтеся власної сіткою або перевизначати готові фреймворки. Відповідно сюди імпортовані папки _mixins. _variables.scss тощо.
Стилі для об'єктів.
Мені ж більше близький підхід SMACSS, де пропонується розсортувати все по папках. Я вважаю за краще зберегти кожен модуль в окремому файлі і потім імпортувати в _modules.scss. Так зручніше редагувати. Також вважають і творці SCSS Bootstrap.
Все, що не ввійшло в зазначені вище папки.