Фронтенд как система,а не набор размеров

Миксины, clamp(), переменные и брейкпоинты. Предсказуемый код вместо ручной подгонки

Что значит «фронтенд как система»

Логика, структура и взаимосвязь решений.

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

  • Размеры считаются через диапазоны, а не фиксируются
  • Отступы подчиняются единому вертикальному ритму
  • Цвета и брейкпоинты вынесены в переменные
  • Блоки не зависят от контекста и порядка на странице

Диапазоны вместо фиксированных значений

Экран воспринимается как непрерывное пространство. Размеры внутри него меняются плавно и последовательно, следуя ширине окна.

В начале задаются базовые переменные и диапазоны. Они определяют пропорции интерфейса, на которых строятся размеры, отступы и масштаб по всей странице.

Цвета

Цвета заранее вынесены в переменные и лежат в :root. Жёстко заданных значений в стилях нет, весь проект использует только эти токены.

Это позволяет быстро управлять палитрой, собирать светлые и тёмные темы без переписывания стилей, поддерживать чистоту интерфейса при росте проекта и не бояться, что где-то встретится другой оттенок «синего».

:root {
--black-true : #000000;
--black : #1C1D26;
--white : #ffffff;
--green : #008B6B;
--blue : #2448FF;
--blue-light : #36A0D5;
--violet : #B575DF;
--red : #E73F3F;
}

Любую переменную можно использовать для текста, фона или бордеров. Меняем здесь, меняется везде

Брейкпоинты

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

$main: 1160px;
$sm : 767px;
$xs : 575px;

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

Шрифты

Шрифты разделены по назначению: для основного текста и для акцентов используются разные семейства. Это упрощает поддержку и делает структуру кода прозрачной.

Если менять шрифт, достаточно обновить переменную — всё автоматически применится во всех компонентах.

$font-family-default: "Nunito Sans", sans-serif;
$font-family-title: "Unbounded", sans-serif;
Так проще держать единый стиль на сайте и не искать, где используется другой шрифт.
Итог

Цвета вынесены в :root, потому что это настройки внешнего вида сайта. Они используются напрямую в CSS и могут легко меняться в одном месте, влияя на весь интерфейс. По такому же принципу туда можно выносить радиусы, отступы и другие значения, если они всегда одинаковые и не зависят от ширины экрана.

Шрифты в :root не выносятся, потому что их не нужно менять во время работы сайта. Шрифт выбирается один раз и дальше просто используется, поэтому удобнее задавать его через SCSS-переменные. Это не усложняет код и не создаёт лишний уровень настроек.

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

CSS clamp() на практике: как я рассчитываю адаптивные размеры

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

Условие для расчёта шрифта

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

Для этого задаём диапазон размеров шрифта и диапазон ширины контейнера. Конкретные числа используются уже в примере расчёта.

Как рассчитывается размер

Для плавного масштабирования используем линейную зависимость:

размер = A + B * vw

  • A — базовый размер, минимальный на маленьком экране
  • B — коэффициент роста, показывающий, насколько размер увеличивается с ростом ширины

После расчёта коэффициенты применяются ко всем элементам через миксины.

Дано конкретные значения для примера:
  • Минимальный размер шрифта: 16px
  • Максимальный размер шрифта: 24px
  • Минимальная ширина контейнера: 390px
  • Максимальная ширина контейнера: 1440px

1vw:

  • 390 → 3.9px
  • 1440 → 14.4px

Ищем A и B в формуле:

A + B * vw = размер

Система уравнений:

  • A + 14.4B = 24
  • A + 3.9B = 16

Вычитаем первое уравнение из второго:

  • (A + 14.4B) − (A + 3.9B) = 24 − 16
  • 14.4B − 3.9B = 8
  • 10.5B = 8
  • B ≈ 0.762

Подставляем:

  • A = 16 − 3.9 × 0.762 ≈ 13.026

Итог:

clamp(16px, calc(13.026px + 0.762vw), 24px)

Пример миксина

// В начале _mixin.scss или любого SCSS-файла
@use 'sass:math';
@mixin fluid-font($min-size, $max-size, $min-screen, $max-screen) {
$b: math.round((($max-size - $min-size) / ($max-screen - $min-screen)) * 100 * 100) / 100;
$a: math.round(($min-size - (($min-screen * ($max-size - $min-size)) / ($max-screen - $min-screen))) * 100) / 100;
font-size: clamp(#{$min-size}px, calc(#{$a}px + #{$b}vw), #{$max-size}px);
}
// Пример использования
h1 {
@include fluid-font(16, 24, 390, 1440);
}
Итог

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

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

Зачем строить систему?

Чтобы правки дизайнера не превращались в ночной кошмар

Например: дизайнер присылает правку, поменяй этот синий на 10% светлее. Без системы это значит:

  • Искать этот цвет на 15 страницах
  • Проверять каждый блок, кнопку, ссылку
  • Вносить правки в десятках мест
  • Рисковать что-то упустить
  • Тратить часы вместо минут

С системой: меняю значение в одной переменной "--blue" и всё обновляется автоматически на всём сайте. За 10 секунд.

Это про практическую пользу

Я создаю фронтенд так, чтобы правки, будь то цвета, отступы или адаптив делались в одном месте. Это экономит:

  • Время

    Минуты вместо часов на каждую правку

  • Бюджет

    Меньше часов работы = ниже стоимость поддержки

  • Нервы

    Никакого «а не забыла ли я что-то»

Документирую то, что действительно работает

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

Устали от бесконечных правок «то тут, то там»? Давайте сделаем ваш сайт управляемым.

Будет пополняться

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

Если интересно что-то конкретное, пишите. Могу разобрать вашу задачу или подсказать, как сделать.