Шесть антипаттернов в вёрстке
2026-02-26 18:41 Diff
https://ru.hexlet.io/blog/posts/shest-antipatternov-v-vyorstke

Как и в любой сфере деятельности человека, в вёрстке можно выделить несколько антипаттернов — действий, которые возможны, но приводят к неприятным ситуациям в будущем или являются неэффективными. Применительно к вёрстке, антипаттерны не позволяют удобно расширять проект и работать другим разработчикам. В этой статье я рассмотрю те антипаттерны, с которыми сталкивался сам. Их знание и умение избегать поможет вам быстро вырасти как верстальщику.

Этот список неполный. Для полного списка нужна не просто статья, а целый обучающий курс. Поэтому будут выделены только основные, которые чаще всего встречаются на практике и портят жизнь разработчикам.

Содержание

Антипаттерн №1. Единицы rem и базовый размер шрифта

Проблема: использование единиц измерения rem с базовым размером шрифта в 10 пикселей.

Нет, речь не о том, что размер шрифта в 10 пикселей — это плохо. С познанием единицы измерения rem разработчики придумали хитрый способ удобного перевода px → rem — выставление для селектора html размер шрифта в 10 пикселей. Действительно, теперь перевод значений становится очень простым:

  • 15px = 1.5rem
  • 27px = 2.7rem

и так далее. Здесь кроется одна большая проблема: пользователи не могут задать минимальный размер шрифта в настройках браузера. Это серьёзно влияет на доступность проектов. Например, слабовидящие люди или люди, у которых монитор находится далеко, увеличивают минимальный размер шрифта. Устанавливая минимальный размер в 18 пикселей, они ожидают, что большинство шрифтов не будут иметь меньший размер. Что будет, если установить такое значение:

Браузер перезапишет пользовательскую настройку.

Решение: не используйте базовый размер шрифта в 10 пикселей. При необходимости установите этот размер не менее 16 пикселей. Для удобного перевода из px и rem можно написать функцию в любом препроцессоре.

Антипаттерн №2. Фиксированная высота блоков

Проблема: повсеместное использование фиксированной высоты блоков

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

При развитии страницы и добавления туда новых блоков всегда нужно будет считаться с тем, что в стилях указана чёткая высота. Нужен новый контент внутри блока? Идём в CSS и увеличиваем размер. Удаляется контент? Идём в CSS и уменьшаем размер. Не самая интересная работа.

Зачастую такое решение используется для того, чтобы избавиться от внутренних отступов и не высчитывать их по макету. Поэтому вся суть проблемы сводится к обычной лени разработчика — стараясь сделать меньше телодвижений сейчас, он обрекает себя на дополнительные телодвижения потом.

Вторая причина такого действия: непонимание работы блочной модели. При добавлении внутренних отступов размер секции может увеличиться, а может не сделать этого. Если упустить этот те��ретический момент, то можно наткнутся на непонимание происходящего. В этом случае куда проще задействовать свойство height и избавиться от головной боли.

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

Антипаттерн №3. Абсолютное позиционирование как способ подгона макета

Проблема: использование абсолютного позиционирования без необходимости в нём.

Этот пункт является прямым продолжение пункта про фиксированную высоту. Как и там, использование абсолютного позиционирования для контента чаще всего является решением следствия проблемы, а не её причины.

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

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

Решение: используйте абсолютное позиционирование только в оправданных случаях. Это может быть создание анимаций, нестандартных секций, взаимодействие с пользователем. Само использование позиционирования не является антипаттерном, но его использование для подгона макета является.

Антипаттерн №4. Pixel Perfect

Проблема: излишние переживания по поводу Pixel Perfect

Так, спокойно. Не стоит сразу думать о том, что автор этой статьи нехороший и ленивый человек.

Pixel Perfect — подход, при котором макет верстается с точностью до пикселя. Это кажется здравой идеей, ведь макет будет перенесён ровно так, как этого хотел заказчик, дизайнер или ваш кот.

Такой подход был максимально актуален во времена небольшого распространения различных устройств, операционных систем, браузеров. Сейчас же каждое новое окружение пользователя может немного по-разному воспроизводить одну и ту же вёрстку. Яркий пример — шрифты. Алгоритмы их отрисовки могут сильно отличаться, что сводит практический смысл Pixel Perfect к нулю. Подстроив макет к одной системе, вы получите расхождения в другой.

Помимо этого, Pixel Perfect часто приводит к проблемам из прошлых пунктов. Именно для соблюдения макета при таком подходе начинаются танцы с бубном в виде фиксированной высоты и странным позиционированием.

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

Решение: отведите допуски под небольшие различия между макетом и его вёрсткой. Отдайте предпочтение чистоте и корректной структуре, а не попиксельному воспроизведению макета.

Антипаттерн №5. Игнорирование методологий

Проблема: написание стилей без использования любой методологии.

Методология — набор правил и решений, которые используются при вёрстке макета. Часто они описывают взаимосвязь блоков между собой и поддержку специфичности внутри таблицы стилей.

Существует несколько популярных методологий, которые используются в проектах по всему миру: БЭМ, OOCSS, Atomic CSS, SMACSS. Все они созданы для поддержания единства написания стилей различными разработчиками. С точки зрения самих стилей методологии позволяют снизить специфичность селекторов, разделить блоки на компоненты и сделать их переиспользуемыми. Часто методологии определяют и архитектуру проекта.

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

  1. Разработчики с трудом будут ориентироваться в стилях друг друга.
  2. Использование сложных селекторов, которые будут «перебивать» стили других селекторов, применяемые к блоку.
  3. Разброс стилей по всему проекту. Это осложнит доработку проекта. Часто это выражается в виде наличия одних и тех же селекторов в разных частях CSS-файла.
  4. Отсутствие согласованности в именовании классов. Вы больше любите сокращённо .btn, а другой разработчик .button. Классы говорят об одном и том же, но имеют разные названия.

Решение: изучите методологии и используйте ту, которая вам больше нравится. Придерживайтесь методологии, которая принята в компании.

Антипаттерн №6. Сокращённые свойства

Проблема: использование сокращённых записей свойств по всему проекту.

Изучив сокращённые записи многих свойств, верстальщики начинают использовать их везде. Это не является антипаттерном само по себе, ведь сокращённые свойства действительно помогают сократить количество кода и иногда сделать его удобнее. Взгляните на пример:

Меньше кода — меньше телодвижений. И это отлично, но за использованием сокращённых свойств стоит одна особенность — они перезаписывают все значения до их написания. Например:

Определите, какие свойства будут у секции? Возможно, вы ожидаете, что в секции будет фоновое изображение и зелёная подложка в виде просто цвета. Но на самом деле это не так — свойство background у селектора .section-green перезапишет все свойства фона. И секция будет иметь только зелёный фон, а картинка пропадёт.

Такое поведение может как помочь разработчику, так и подпортить ему нервы.

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