10 полезных практик при написании CSS
2026-02-26 20:00 Diff
https://ru.hexlet.io/blog/posts/10-poleznyh-praktik-pri-napisanii-css

Написание таблиц стилей не заканчивается использованием свойств и подбором значений исходя из шаблона. Это объёмный процесс, который включает:

  • Грамотное именование
  • Структурированность
  • Понятность селекторов
  • Хорошую переиспользуемость
  • Соответствие принципам доступности
  • Оптимизацию

Кто-то считает CSS простым языком, кто-то его боится, но использование правильных подходов к его написанию позволит не допускать многих ошибок. Чем больше проект, тем сложнее выглядит CSS, а хорошая его поддержка — работа верстальщика. Только в его силах сделать так, чтобы стили можно было переиспользовать, а сам рабочий файл выглядел удобным для работы.

В этой статье я расскажу о своём подходе к практикам в CSS и тех вещах, которые считаю важными в разработке.

Содержание

Практика № 1: организация рабочей среды

Запись стилей напрямую в файл .css может сопровождаться различными проблемами. Множество ошибок в проекте случается из-за забытой точки с запятой или неправильно закрытой фигурной скобки. Частое копирование одних и тех же CSS-стилей тоже не приносит удобства для будущих изменений.

Сейчас существует много инструментов, которые позволяют автоматизировать процессы вёрстки и сделать написание CSS более осмысленным. В первую очередь это использование препроцессоров. Неважно, какой именно вы используйте препроцессор: SASS, Less или Stylus — они позволяют удобнее выносить повторяющийся CSS, а так же определить функции для работы с кодом.

Сравните написание одного и того же кода с помощью CSS и препроцессора SASS

Главное отличие заключается в добавлении новых иконок. В случае с CSS необходимо вручную добавлять все новые иконки и, для правильной структуры, указывать новые иконки рядом со старыми. Это потребует постоянного перемещения по CSS файлу, который может быть достаточно большим.

В случае с SASS был определён миксин, который генерирует иконку в зависимости от переданных данных и цикл, в котором вызывается миксин. Для добавления новых иконок достаточно изменить массив $icons. Остальное препроцессор сделает за нас.

Другим удобным инструментом является постпроцессор. Если препроцессор позволяет добавить новую логику в CSS и в конечном итоге скомпилировать всё в чистый CSS, то постпроцессор работают с уже конечным файлом стилей. Он позволяет проставить все необходимые префиксы, перенести медиазапросы в конец файла и так далее. Самым популярным постпроцессором является PostCSS.

Последним в списке, но не по назначению, является линтер — пакеты, которые проверяют CSS на следование стандартам. Это позволяет стандартизировать стили и не допустить досадных ошибок. Самым популярным линтером для CSS на сегодня является Stylelint. Именно его можно увидеть при прохождении курсов по вёрстке на Hexlet.

Сравните код, который написан без использования линтера:

и с линтером:

Теперь стили удобно сгруппированы по типу свойств, а также исправлено указание единицы измерения при нулевом значении свойства margin.

Также полезно:

Как работать с форматом SVG руководство для начинающих веб-разработчиков

Практика № 2: (не) использование фреймворка

CSS-фреймворк — набор модулей, компонентов и расширений, которыми можно пользоваться в проекте. Одним из самых популярных фреймворков на сегодня является Bootstrap. Это мощный инструмент, но надо понимать, что загрузка Bootstrap негативно сказывается на времени загрузки всего проекта. Минифицированный файл стилей Bootstrap 4 весит 156 килобайт. Для корректной работы также необходимы JavaScript-файлы.

Если при использовании фреймворка необходима только небольшая его часть, то стоит скомпилировать только ту часть CSS, которая необходима в проекте. Bootstrap предоставляет все SASS файлы, из которых можно взять только самое необходимое.

Если ваш проект небольшого размера, то стоит задуматься, а нужен ли там фреймворк. Возможно потратив лишние пол часа на написание своих стилей, вы ускорите загрузку сайта в несколько раз.

Другой крайностью является неиспользование фреймворка в больших проектах, которые расширяются. Это не обязательно должен быть открытый фреймворк. Он может быть написан внутри компании. Такое решение позволит удобно переиспользовать компоненты: кнопки, уникальные блоки, формы.

Читайте также:

Зачем изучать HTML и CSS, или Когда роботы заменят верстальщиков на рынке труда

Практика № 3: разделение стилей

Если вы используете препроцессоры, используйте функцию импорта файлов. Это позволит не складировать весь код препроцессора в одном единственном месте. В этом случае вы получите такой же неудобный для редактирования код, как и при использовании одного CSS-файла. Разделите части вашего кода и создайте для них отдельные файлы. Также создайте главный файл, в который и подключите все остальные файлы. При компиляции препроцессор соберёт воедино все файлы, и вы получите один CSS-файл со всеми стилями.

Пример на SASS. Главный файл:

Этот пример плавно подводит к следующему пункту.

Практика № 4: переменные для настроек проекта

Каждый проект имеет стандартные настройки, которые переиспользуются или являются глобальными. Такими настройкам чаще всего являются:

  • Цветовая схема
  • Отступы
  • Шрифт
  • Базовый размер шрифта

Используя препроцессор, можно указать все стили в едином файле variables или settings. Теперь управление базовыми настройками будет происходить из одного файла.

Читайте также

Зачем изучать HTML и CSS, или Когда роботы заменят верстальщиков на рынке труда

Практика № 5: уменьшение специфичности

Уменьшая специфичность селекторов, вы не только увеличиваете читаемость кода, но и уменьшаете конечный размер CSS-файла. Взгляните на следующий пример:

Кажется, что он не имеет каких-то проблем, но на самом деле сейчас он привязан только к определённой структуре HTML. Если возникнет необходимость стилизовать другой элемент этими правилами, то нужно создать новый селектор и прописать стили в нём.

Уменьшив специфичность, можно использовать класс на любом HTML-элементе при любой структуре.

Практика № 6: группировка стилей

В статье Что верстальщик должен знать про OOCSS и организацию CSS описывалась одна из распространённых методологий — OOCSS. Она позволяет разделять структурные и визуальные стили элемента. Помимо такого разделения использование методологий позволяет не дублировать повторяющиеся стили.

Распространённый пример:

В примере находятся стили для двух кнопок, но они различаются только одним свойством. Остальные стили полностью повторяются. Это приводит к невозможности быстро изменить общие стили для кнопок. Решение достаточное простое — выделить отдельный класс под структурные свойства.

Данный приём доступен как для CSS, так и для препроцессоров. Некоторые методологии ориентированы на полную изоляцию модулей друг от друга. В таком случае можно использовать миксины и переменные для создания таких стилей. Главное — возможность изменения свойств в одном месте. Вот как это может выглядеть на SASS:

Практика № 7: построение стилей от общего к частному

Хорошей практикой является написание CSS от общих стилей к более частным. Это означает, что в самом верху определяются общие стили в виде селекторов по тегу, а после них все остальные. При этом сами селекторы, после общих, стоит выделить в отдельные разделы, такие как:

  • Общие классы (утилиты, атомарные классы)
  • Классы, отвечающие за общий вид страницы
  • Классы для различных компонентов

Использование комментариев поможет в быстром ориентировании внутри CSS-файла.

Практика № 8: использование инлайновых стилей

Скажите нет инлайновым стилям. Они имеют наибольший приоритет, и их использование может сильно помешать при кастомизации проекта. Чаще всего инлайновые стили нужны при использовании JavaScript, когда сайт реагирует на действие пользователя. Например, при анимации. В этом случае использование инлайн-стилей оправдано.

Также полезно:

HTML/CSS как центрировать по вертикали

Практика № 9: добавление focus к интерактивным элементам

Верстальщики часто добавляют новые интерактивные элементы, которые не знает браузер. Это могут быть кастомные чекбоксы, радиокнопки, кнопки отправки сообщения и так далее. Для удобства используют не стандартные теги, которые предназначены для таких взаимодействий, а простые <div></div> и <span></span>. Здесь кроется главная опасность: проставляя таким элементам стили при наведении с помощью :hover, разработчики забывают про пользователей, которые используют клавиатуры.

Для них эти интерактивные элементы могут быть недоступны, или они просто не смогут понять, что находятся на нём при использовании клавиатуры. Чтобы избежать этой ошибки, следует придерживаться нескольких правил:

  • При возможности используйте стандартные HTML-элементы для интерактивных элементов. Даже при случае несовпадения этих элементов с дизайном постарайтесь оставить стандартное отображение или вносите небольшие изменения.
  • Не удаляйте focus у интерактивных элементов. Если такой элемент скрыт в угоду кастомизации, добавьте фокус для новых элементов.
  • Убедитесь, что ваши интерактивные элементы могут взаимодействовать с клавиатурой.

Практика № 10: именование классов

Не стоит забывать про хорошее именование классов. Идеально, если название класса описывает то, что происходит на странице или какой блок перед нами. Подробнее об этом я описывал в статье Ошибки именования в вёрстке. Вот небольшой пример неудачного именования:

Помимо различного вида именования, здесь указан чёткий порядок классов. Если в HTML-элементы поменяются местами, то весь смысл таких классов исчезнет. Определяйте название класса исходя из того, что за элемент перед вами или какие характеристики он имеет. Здесь всё зависит от той методологии, которой вы придерживаетесь.