Приветствую. Представляю вашему вниманию перевод статьи How I Structure My CSS (for Now), опубликованной 11 августа 2020 года автором Matthias Ott
Когда вопрос касается структурирования CSS, нет недостатка различных соглашений об именовании, методологий и архитектур. Будь то BEM, OOCSS, SMACSS, ITCSS или CUBE CSS - за последние годы появилось много разных подходов к управлению модульным CSS. Одни предлагают стратегии разделения CSS на небольшие, лучше поддающиеся управлению фрагменты, другие больше сосредотачиваются на соглашениях об именовании классов. Порой сложно понять, в чём отличия или преимущества определённых методик, но у всех них, в конце концов, одна цель обеспечить единую структуру и принципы при работе в команде с другими людьми или с самим собой в будущем.
Неудивительно, что в начале каждого нового проекта я обдумываю структуру CSS, а со временем выбранный способ организации и написания кода существенно меняется. Самое большое изменение произошло, когда мы все начали писать CSS для компонентов. Хотя, и препроцессоры, такие как Sass, заметно на это повлияли.
В этой статье я поделюсь своим текущим принципом структурирования CSS. В нём я не придерживаюсь какой-либо определённой методологии, хотя те, кто знаком с ITCSS Гарри Робертса, определённо увидят сходства. Если вы ещё не знакомились с ITCSS, настоятельно рекомендую это сделать. Больше всего в этой методологии мне нравится прагматичный, полностью прикладной подход и принцип структурирования, делающий CSS всё более конкретным и явным по мере продвижения вниз по структуре. Это облегчает работу с каскадом и наследованием селектора, оставляя количество классов их специфичность на низком уровне. Существует, однако, и несколько отличий, и это именно то, что я предлагаю любому, кто создаёт свою собственную структуру: берите любую методологию и свободно адаптируйте её к своим потребностям и способу работы.
Структура основной папки
Вот так в данный момент выглядит структура моей папки. Давайте разбираться
/scss/ 1-settings 2-design-tokens 3-tools 4-generic 5-elements 6-skeleton 7-components 8-utilities _shame.scss main.scss
Настройки
Первая папка 1-settings
предназначена для общих
настроек проекта, самой базовой конфигурации. Это может быть набор
глобальных переменных: Sass-переменных или CSS-переменных
1-settings _global.scss
Дизайн-токены
Вторая папка предназначена для стилей, касающихся визуального оформления сайта. Мы всё ещё не пишем правила, предназначенные для стилизации разметки. Здесь мы определяем переменные для шрифта, цветов, отступов, медиа-запросов и всего остального, что будем использовать при вёрстке. Эти атрибуты визуального оформления принято называть "дизайн-токенами". Их значения могут быть взяты из дизайн-системы вашего проекта.
2-design-tokens _colors.scss _fonts.scss _media-queries.scss _spacing.scss _typography.scss
Инструменты
Папка "Tools" предназначена для ваших глобальных Sass-миксинов и функций. Возможно, вы захотите управлять цветами с помощью режимов смешивания (blend-mode) или установить соотношение сторон для элемента, содержащего видео? Или применить "clear" для каких-то float-элементов. Сам я не особо использую миксины, но знаю много людей, которые их любят.
3-tools _aspect-ratio.scss _blend-modes.scss _center.scss _clearfix.scss _gradients.scss
Общие стили
Как и в методологии ITCSS, "generic" - первая папка, в которую помещаются стили для оформления разметки. Она содержит глобальные правила "box-sizing", сброс CSS или стили для печати - всё, что должно быть задано в самом начале CSS, но еще не зависит от конкретного проекта.
4-generic _box-sizing.scss _font-face.scss _normalize.scss _print.scss
Элементы
Теперь, когда базовые правила установлены, мы можем приступить к стилизации строительных блоков нашего интерфейса: основных элементов HTML. В основном не используя классы, мы переопределяем основные стили браузера для оформления заголовков, кнопок, ссылок, списков и т.д., благодаря чему можем быть уверены, что все компоненты в проекте будут иметь одну и ту же базу.
5-elements _forms.scss _headings.scss _images.scss _links.scss _lists.scss ...
Скелет
Любой современный веб-проект, создаваемый с использованием компонентов, требует структуры, рассчитанной для этого: обёртки, контейнеры, гриды, всевозможные переиспользуемые объекты, которые образуют раскладку. Это скелет вашего сайта.
6-skeleton _grid.scss _layouts.scss _objects.scss
Компоненты
Сердце проекта. Здесь мы разрабатываем компоненты интерфейса. В
нескольких последних проектах я даже отделял большие модули и
маленькие компоненты, но вместо этого можно просто вкладывать
компоненты друг в друга. Если нравится, можете использовать
префиксы и соглашение об именовании, такое как
BEM. Недавно я остановился на BEM-подобном, но более упрощённом
соглашении об именовании. Суть в том, чтобы использовать как можно
более простые, но информативные имена классов и разделять элементы
и их содержимое чертой. Например, .card
и
.card-content
. Иногда, когда я работаю с Fractal, CSS
для отдельных компонентов может также находиться в другой папке
вместе с HTML и JavaScript-кодом. В этом случае папка с
компонентами может быть пустой или содержать
@import@
.
7-components _accordion.scss _card.scss _hero.scss _pan-galactic-gargle-blaster.scss ...
Утилиты
Ещё одна папка? Да, но эта - последняя. Папка "utilities"
содержит служебные и другие полезные классы и, самое главное,
состояния и модификаторы, такие как .is-active
или
.visually-hidden
. Эти стили переопределяют стили
предыдущих слоёв и часто устанавливаются через JavaScript. Мне
очень нравится предложение Andy Bell в его
методологии CUBE CSS использовать data-атрибуты для изменения
состояния компонентов, что также полезно с точки зрения большей
специфичности.
8-utilities _modifiers.scss _states.scss
_shame.css
Этот файл является ещё одной идеей Harry Roberts и предназначен для всех постыдных CSS-решений, таких как быстрые фиксы и хаки, которые могут выступить временным решением, но позже должны быть реализованы как полагается. Обязательно документируйте все эти временные меры с помощью комментариев. Почему вы реализовали это именно так? Есть ли у вас идея, как сделать лучше? Что для этого нужно? И так далее.
Собираем всё вместе
Наконец, файл main.scss
, собирающий все части
воедино. Я предпочитаю явно импортировать каждый файл в отдельной
строке вместо импорта всех папок, потому что это даёт больше
контроля над последовательностью подключения. Но это, конечно,
личное дело каждого.
@charset "UTF-8";// 1. Settings@import "1-settings/global"; // 2. Design Tokens@import "2-design-tokens/colors", "2-design-tokens/fonts", "2-design-tokens/media-queries", "2-design-tokens/spacing", "2-design-tokens/typography";...
Вот и всё. Такая структура хорошо проявила себя в последних проектах, потому что помогает поддерживать порядок. Получаемый CSS также намного чище, что облегчает поиск нужного фрагмента кода, если нужно внести изменения или исправить ошибки.
На днях я делал опрос в Твиттер о предпочитаемой CSS-методологии:
Всем нравится использовать свой собственный CSS, и это здорово. Если вы используете методологию или структуру папок, которыми хотели бы поделиться, напишите об этом пост, и я с радостью дам ссылку на него здесь. Было бы интересно посмотреть, как вы структурируете свой CSS.
Итоговая структура папок:
/scss/ 1-settings _global.scss 2-design-tokens _colors.scss _fonts.scss _media-queries.scss _spacing.scss _typography.scss 3-tools _aspect-ratio.scss _blend-modes.scss _center.scss _clearfix.scss _gradients.scss 4-generic _box-sizing.scss _font-face.scss _normalize.scss _print.scss 5-elements _forms.scss _headings.scss _images.scss _links.scss _lists.scss ... 6-skeleton _grid.scss _layouts.scss _objects.scss 7-components _accordion.scss _card.scss _hero.scss _pan-galactic-gargle-blaster.scss ... 8-utilities _modifiers.scss _states.scss _shame.scss main.scss