Плавні відступи з CSS clamp(): padding і margin, що природно шкалюються

January 28, 2026 • February 3, 2026 • Читання: 6 хв • Views: 6

Було корисно?

Ви знаєте цей запах: «проста» лендинг-сторінка перетворюється на купу одноразових переозначень padding, винятків для брейкпоінтів і
зсувів макета, які помічаються тільки на чому-небудь ноутбуці з масштабуванням 125%. Потім маркетинг хоче новий хедер, і раптом
правила відступів починають інтерпретуватися по-своєму на різних ширинах вікна.

Плавна система відступів на основі clamp() не скасовує дизайнерські рішення — але вона усуває цілу категорію
крихкої математики брейкпоінтів і археології типу «чому тут 37px». Так ви отримуєте padding і margin, які масштабуються природно,
залишаються придатними для налагодження і не будять вас о 02:00.

Чому `clamp()` — правильний інструмент для відступів

Відступи — це те місце, де дизайн-системи гинуть. Типографіка отримує увагу. Кольори — керованість. Відступи — «приб’ємо це пізніше»,
що корпоративною мовою означає «ми відпускаємо ентропію».

Традиційні адаптивні відступи покладаються на брейкпоінти: при 768px ставимо padding 24px, при 1024px — 32px і так далі.
Це зрозуміло, але породжує жорсткі кроки. Користувачі не сприймають екрани як набір дискретних ширин; вони бачать континуум —
особливо на десктопі, де змінювання розміру вікна, розділені екрани та масштабування — звична справа.

clamp(min, preferred, max) — простий контракт:

Нижче певного діапазону відступи не стануть меншими за min.
Всередині діапазону відступ слідує за preferred (зазвичай це fluid-вираз).
Понад діапазон відступ не перевищить max.

Для токенів відступів це — золото: можна виразити «повинно трохи масштабуватися з вьюпортом, але ніколи не виходити з розумних меж».
Ваші макети перестають стрибати на брейкпоінтах і починають виглядати продуманими.

Один цитат, який варто тримати в голові при цьому:
Надія — не стратегія. — Gene Kranz

Жарт №1: система відступів, що лише на брейкпоінтах, — як RAID 0: швидко налаштувати, ефектно в демо і стиль життя в продакшені.

Цікаві факти та коротка історія

Система відступів не існує у вакуумі; це результат еволюції CSS і того, як працюють дизайн-команди. Ось кілька конкретних, корисних
контекстів, що пояснюють, чому clamp() став «дорослим» у кімнаті.

Viewport-одиниці (vw, vh) з’явилися в CSS Values and Units Level 3, і дизайнери відразу почали
пробувати масштабувати все ними — включно з відступами. Це працювало, доки не переставало: великі екрани робили padding величезним.
Ранній адаптивний дизайн був орієнтований на брейкпоінти, бо медіа-запити були основним інструментом. Флюїдна математика
була можлива, але важка; більшість команд воліла передбачувані кроки.
Ера «вертикального ритму» (базові сітки, послідовні line-height) підштовхнула команди трактувати відступи як систему, а не як
настрій. Такий підхід досі важливий, навіть якщо ключове слово пішло з ужитку.
Відступи на основі rem стали популярними із зростанням уваги до доступності — прив’язка відступів до кореневого
розміру шрифта зробила масштабування та налаштування користувача менш проблемними.
calc() зробив флюїдні розміри більш поширеними, але також створив нечитаємий CSS. Багато команд виявилися з «магічними формулами»,
до яких ніхто не хотів торкатись.
clamp() став широко доступним, коли браузерна підтримка укріпилась. Саме тоді флюїдні розміри перестали бути бутик-технікою
і стали розумним дефолтом для відступів і типографіки.
Дизайн-токени стали одержимістю крос-платформено (веб + натив + документація). Токени відступів — одні з найбільш ефективних,
бо зменшують «рандомні пікселі» в компонентах.
Сучасний CSS додав container queries, що знову змінює дискусію: тепер можна масштабувати відступи від розміру контейнера, а не тільки вьюпорта.
Але clamp() залишається корисним і в цих запитах.

Модель: min / preferred / max (і що насправді означає «preferred»)

Найпоширеніша помилка з clamp() — неправильне розуміння середнього аргументу.
Люди трактують його як «ідеальне значення», а не як «флюїдний вираз, який буде обмежений».

Думайте про clamp() як про захисний конверт навколо формули. Формулі дозволено рухатися, але тільки в межах
парканів min і max.

Що варто обмежувати clamp

Padding (внутрішні відступи компонента)
Margins (відступи між компонентами)
Gaps (gap у flex/grid; недооцінено)
Вбудовані відступи (padding кнопок, відступи бейджів)

Що варто обережно обмежувати clamp

Критичні для макета розміри (наприклад, ширини для колонок навігації), якщо немає жорстких обмежень і покриття тестами.
Флюїдні відступи прощають помилки; флюїдні ширини макета можуть спричинити хаос.
Все, пов’язане з довжиною контенту (наприклад, відступи, що припускають, що заголовки не переносяться). Ваші заголовки перенесуться.

Розумний дефолт для відступів: rem + vw

Практичний патерн — задавати min і max у rem (дружньо для доступності) та використовувати preferred, який змішує
rem і vw.

Приклад-концепт (не копіюйте сліпо):

cr0x@server:~$ cat /tmp/example.css
:root {
  --space-s: clamp(0.75rem, 0.5rem + 0.8vw, 1.25rem);
}

Це читається як: «малий відступ принаймні 0.75rem, трохи масштабується з вьюпортом, але ніколи не більше 1.25rem.»
Відчувається природно на різних пристроях, бо термін з вьюпортом забезпечує поступове зростання, а rem прив’язує до налаштувань шрифта користувача.

Практична система токенів: відступи, які можна відправляти в продакшн

Система відступів — це контракт між дизайном і інженерією. Якщо вона надто хитра, її не використовуватимуть. Якщо занадто вільна — не буде системою.

Мені подобається двошарова модель:

Примітиви: невеликий набір флюїдних токенів відступів (--space-1…--space-8).
Семантичні псевдоніми: токени на рівні компонентів за наміром (--card-padding, --page-gutter).

Примітиви стабільні. Семантика еволюціонує разом з інтерфейсом. Коли відбувається редизайн, ви повинні змінювати семантику частіше, ніж примітиви.

Примітиви відступів: приклад шкали

Ось набір токенів, який добре працює для типової гібридної SaaS/dashboard/маркетингової розмітки. Припускається, що ваш «комфортний»
діапазон вьюпорта приблизно 360px–1280px, але він не вибухає поза цим через межі clamp.

cr0x@server:~$ cat /tmp/spacing-tokens.css
:root {
  /* Base: tune once, then stop touching every component. */
  --space-1: clamp(0.25rem, 0.20rem + 0.20vw, 0.40rem);
  --space-2: clamp(0.50rem, 0.40rem + 0.35vw, 0.75rem);
  --space-3: clamp(0.75rem, 0.60rem + 0.55vw, 1.10rem);
  --space-4: clamp(1.00rem, 0.80rem + 0.80vw, 1.60rem);
  --space-5: clamp(1.50rem, 1.20rem + 1.10vw, 2.30rem);
  --space-6: clamp(2.00rem, 1.60rem + 1.40vw, 3.00rem);
  --space-7: clamp(3.00rem, 2.40rem + 2.00vw, 4.50rem);
  --space-8: clamp(4.00rem, 3.20rem + 2.60vw, 6.00rem);

  /* Semantic aliases: override here, not in random components. */
  --page-gutter: var(--space-5);
  --card-padding: var(--space-4);
  --stack-gap: var(--space-3);
  --form-row-gap: var(--space-2);
  --section-padding-y: var(--space-7);
}

Це не «правильна» шкала. Це приклад форми, яку ви хочете:
маленькі кроки внизу, більші стрибки зверху і жорсткі обмеження, щоб 5K-монітори не перетворили UI на басейн.

Як використовувати токени, не перетворивши CSS на святинею

Правила, які підтримують систему живою:

Компоненти використовують семантичні токени, де можливо. Це дозволяє змінити відчуття глобально.
Утиліти використовують примітиви. Утиліти — для композиції; примітиви — це атоми.
Жодних сирих пікселів у компонентах, якщо ви не можете це захистити на код-рев’ю без підвищення голосу.

Як правильно рахувати fluid-значення без самообману

Більшість рецептів clamp в інтернеті пропускають важливу частину: переконатися, що ваш «preferred» вираз досягає задуманої min і max при
розумних ширинах. Якщо ви не зробите цієї математики, ви просто сподіваєтеся, що CSS поводитиметься.

Потрібні три рішення:

Мінімальний відступ при малому вьюпорті (або ширині контейнера)
Максимальний відступ при великому вьюпорті (або ширині контейнера)
Діапазон інтерполяції: ширини, на яких відбувається масштабування

Надійний підхід: визначте дві точки і виведіть нахил

Припустимо, ви хочете токен, який:

16px при ширині вьюпорта 360px
28px при ширині вьюпорта 1280px

Переведіть у rem, якщо ви використовуєте rem-базу (припустимо корінь 16px):

16px = 1rem
28px = 1.75rem

Термін «preferred» часто виглядає як:
calc(Arem + Bvw).
Тут B — це нахил: наскільки значення зростає зі збільшенням вьюпорта.

При ширині w, 1vw = w/100 пікселів. Тому Bvw дорівнює B * w / 100 пікселів.
Ваше завдання — вирішити A і B так, щоб:

При w=360: A + B*3.6px = 16px
При w=1280: A + B*12.8px = 28px

Ви можете вирішити це вручну або за допомогою маленького скрипта, але ключовий момент: ви визначаєте пряму між двома точками.
Потім clamp() накладає жорсткі межі у випадку, якщо вьюпорт виходить поза вибраний діапазон.

Жарт №2: якщо ви не записали припущення про min/max, ваша система відступів все одно матиме припущення — просто хитріші.

Виберіть діапазон вьюпорта свідомо

Багато команд несвідомо проектують під брейкпоінти, які вже є. Не робіть так. Оберіть діапазон, що відповідає вашому продукту:

Мобільні: 360–430 — реальна рекомендація, але тестуйте й менші.
Десктопні колонки контенту: 1024–1440 — тут відбувається реальна зміна «відчуття».
Ультраширокі: вирішіть, чи обмежуєте ширину контенту; якщо так — відступи теж можна обмежити.

Якщо ви обмежуєте ширину контенту через max-width-контейнер, флюїдна поведінка, заснована на вьюпорті, переважно впливає на гутери та
навколишній простір. Часто це саме те, що потрібно.

Патерни реалізації: компоненти, контейнери та утиліти

Патерн 1: контейнер + гутери, що масштабуються

Стабільний патерн макета: утримуйте читаємість контенту за допомогою max-width-контейнера і дозволяйте гутерам масштабуватися з вьюпортом.
Контейнер запобігає «рядки стають романом», а флюїдні гутери не дають сторінці виглядати стислим на середніх ширинах.

cr0x@server:~$ cat /tmp/layout.css
:root {
  --container-max: 72rem;
  --page-gutter: clamp(1rem, 0.5rem + 2.5vw, 3rem);
}

.page {
  padding-inline: var(--page-gutter);
}

.container {
  max-width: var(--container-max);
  margin-inline: auto;
}

Рішення: якщо дизайн-команда просить «трохи більше дихання» на десктопі, це вирішує проблему без нових брейкпоінтів.

Патерн 2: padding компоненту через семантичний токен

Не вплітайте флюїдну математику в кожен компонент. Винесіть її в токен один раз.

cr0x@server:~$ cat /tmp/card.css
:root { --card-padding: clamp(1rem, 0.8rem + 1vw, 1.75rem); }

.card {
  padding: var(--card-padding);
  border-radius: clamp(0.5rem, 0.4rem + 0.3vw, 0.8rem);
}

Зверніть увагу на clamp для border-radius. Це не обов’язково, але зберігає відчуття: величезний padding з крихітним радіусом виглядає дивно.

Патерн 3: утиліти стеків з `gap`

Якщо ви все ще розставляєте відступи у стекових елементах через margin-bottom повсюдно, ви платите відсотки за баги в макеті.
Використовуйте утиліту stack з gap, щоб відступи залишались в моделі лейаута.

cr0x@server:~$ cat /tmp/stack.css
.stack {
  display: flex;
  flex-direction: column;
  gap: var(--stack-gap, var(--space-3));
}

Рішення: якщо ви постійно боретесь із «margin останнього елемента», це — протиотрута.

Патерн 4: токени clamp + container queries (коли готові)

Флюїдна поведінка на основі вьюпорта добра, але іноді компоненти живуть у сайдбарах, модалках і розділених панелях.
Container queries дозволяють відступам реагувати на реальну доступну ширину компонента.

Ви все ще можете використовувати clamp() всередині container query-блоків.

cr0x@server:~$ cat /tmp/container-query.css
.panel {
  container-type: inline-size;
}

@container (min-width: 42rem) {
  .panel .card {
    --card-padding: clamp(1.25rem, 1rem + 0.6vw, 2rem);
  }
}

Рішення: якщо ваш додаток складається з ресайзабельних панелей, container queries + clamp-токени перевершать логіку, орієнтовану лише на вьюпорт.

Три корпоративні міні-історії (реалістично, анонімізовано)

1) Інцидент через неправильне припущення: «Наші користувачі всі на сучасних браузерах»

Середня команда дашборду випустила сяючий редизайн з флюїдними токенами відступів, сильно покладаючись на clamp(),
gap і сучасні селектори. У стенді все виглядало чудово. На демо — теж. У всіх на MacBook — теж.

Перший тикет відслужив урядовий клієнт на заблокованому Windows-образі. Їхній браузер не був старезним, але відставання в підтримці викликало
деградацію частини лейаута. Поведінка не була катастрофічною — екран не пустував — але відступи схлопнулися у ключових робочих процесах.
Кнопки злиплися. Мастило форм перетворилося з «чистого» на «щось на зразок перевантаженої таблиці».

Інженери спочатку трактували це як одноразовість: «Нехай оновлять браузер». Це не варіант — у клієнта були вимоги відповідності.
Вони не могли міняти налаштування заради вашої системи відступів.

Виправлення полягало не в тому, щоб прибрати clamp(), а в побудові стратегії прогресивного покращення: визначити розумні
статичні дефолти спочатку, а потім перевизначати clamp там, де підтримується. Вони також додали перевірку підтримки браузера в чекліст релізу
і канарне середовище, що імітує клієнтські обмеження.

Висновок: припущення про клієнтів — це залежності продакшена. Трактуйте їх як версії ядра. Записуйте.

2) Оптимізація, що відкотилася: «Зведемо токени, зробивши все похідним від однієї базової формули»

Інша команда хотіла максимум консистентності. Вони створили концепт «майстер-функції відступів» — один базовий токен, що флюїдно масштабується,
і виводили всі кроки через множники всередині calc(). Це було елегантно. І крихко.

Проблема виявилась під час оновлення бренду. Дизайн хотів трохи щільніші малі відступи, але ті самі великі відступи.
З підходом множників зміна базового токена зміщувала все непередбачувано. Картки стали щільніші, ок — але padding модалок став тісним.
Декілька компонентів з «тонко налаштованими» множниками вийшли з-під специфікації тонкими способами.

Інженери провели дні в погоні за візуальними дифами по десяткам екранів. Система була «послідовною», але некерованою.
Послідовність — не те саме, що керованість.

Вони відкотили підхід з єдиною базою і повернулись до невеликого набору незалежно обмежених примітивів. Так, це більше чисел.
Але це були стабільні числа. Стабільність перемагає.

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

3) Нудна, але правильна практика, що врятувала: «Візуальні регресійні тести для токенів відступів»

Продуктова організація з кількома фронтенд-сквадрами мала проблему: зміни «трохи» в одному відступі витікали в інші місця.
Хтось підправляв padding бічної панелі і випадково робив форми чекауту такими, ніби їх спроектувала інша компанія.

Виправленням не була ще одна зустріч. Вони зробили крихітну «лабораторію відступів» в додатку: сітку компонентів у типових станах
(дефолт, помилка, щільний режим, довгий текст). Підчепили це до CI з скриншот-дифами на декількох ширинах.

Було нудно. Але це була найкраща оборона від випадкового дрейфу. Коли хтось змінював --space-3, вони відразу бачили,
які компоненти змінились, на яких ширинах і наскільки. Розмова в рев’ю стала конкретною, а не емоційною.

Під час пізнішого інциденту, викликаного зміною в CSS-білді, лабораторія виявила проблему до продакшена.
Жодної героїчної сесії налагодження. Жодної війни в кімнаті. Просто провалений CI і фікс.

Висновок: якщо токени відступів — інфраструктура, вони заслуговують тестів як інфраструктура. Скриншоти не гламурні; вони — страховка.

Швидкий план діагностики

Коли флюїдні відступи «виглядають неправильно», потрібно швидко знайти вузьке місце. Не артистично. У стилі «ми розгортаємо за годину».
Ось порядок, яким я користуюсь.

1) Перевірте, чи токен взагалі застосовується

Інспектуйте елемент і підтвердіть, що обчислене значення padding/margin/gap — те, що ви очікуєте.
Якщо ні: маєте справу з каскадом/специфічністю/порядком, а не з матемatikою clamp.

2) Перевірте, чи clamp за межами при поточній ширині

При поточній ширині вьюпорта обчислене значення рівне min чи max?
Якщо воно «запінене»: ваш preferred-вираз поза діапазоном; токен фактично статичний на цій ширині.

3) Переконайтесь, що мікс одиниць має сенс

Чи змішуєте ви px, rem і vw непослідовно між токенами?
Якщо користувацьке масштабування змінює кореневий шрифт, rem-мин/макс будуть змінюватись; px — ні.

4) Виключіть обмеження контейнера та обрізання

Чи елемент знаходиться всередині фіксованого або max-width контейнера, що змінює сприйняті відступи?
Чи є обрізання через overflow або правило вирівнювання flex/grid, що стискає простір?

5) Перевірте зсуви макета, спричинені підвантаженням шрифтів або динамічним контентом

Якщо відступи виглядають добре, а потім зсуваються: можливо, це шрифти, а не токени відступів.
Системи відступів часто звинувачують у всьому. Іноді це несправедливо.

Практичні завдання з командами: перевірити, відлагодити, вирішити

Працювати з відступами — це фронтенд, але дисципліна продакшена все ще важлива: відтворити, виміряти, ізолювати, вирішити.
Нижче наведені завдання, які можна виконати локально або в CI. Кожне містить: команду, що означає вивід і рішення.

Завдання 1: Перевірити, де використовується `clamp()` в кодовій базі

cr0x@server:~$ rg -n "clamp\(" src styles
src/styles/tokens/spacing.css:4:  --space-1: clamp(0.25rem, 0.20rem + 0.20vw, 0.40rem);
src/styles/components/card.css:2: --card-padding: clamp(1rem, 0.8rem + 1vw, 1.75rem);

Значення виводу: ви отримуєте точні файли/рядки використання. Якщо clamp розкиданий по компонентах, контроль вже втрачається.

Рішення: централізувати в токенах, якщо використання довільне; залишати clamp на рівні компонентів лише для дійсно специфічної геометрії.

Завдання 2: Перелічити токени відступів і перевірити узгодженість імен

cr0x@server:~$ rg -n "^\s*--(space|page-gutter|card-padding|stack-gap)" src/styles/tokens/spacing.css
3:  --space-1: clamp(0.25rem, 0.20rem + 0.20vw, 0.40rem);
4:  --space-2: clamp(0.50rem, 0.40rem + 0.35vw, 0.75rem);
12: --page-gutter: var(--space-5);
13: --card-padding: var(--space-4);

Значення виводу: підтверджує, що токени там, де ви очікуєте, і чи змеплені семантики.

Рішення: якщо семантика прямо вбудовує clamp-формули, аудит буде складнішим; краще мапити семантику на примітиви.

Завдання 3: Виявити сирі піксельні відступи в компонентах

cr0x@server:~$ rg -n "(padding|margin|gap)\s*:\s*[0-9]+px" src/styles/components
src/styles/components/banner.css:19: padding: 24px 16px;
src/styles/components/modal.css:44: gap: 12px;

Значення виводу: це налаштування відступів в яких обходять систему токенів.

Рішення: конвертуйте в семантичні токени, якщо немає очевидної причини (наприклад, піксельна вирівняність іконки, прив’язана до ресурсу).

Завдання 4: Перевірити обчислені значення на кількох ширинах вьюпорта за допомогою Playwright

cr0x@server:~$ node -e '
const { chromium } = require("playwright");
(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  for (const w of [360, 768, 1280]) {
    await page.setViewportSize({ width: w, height: 900 });
    await page.goto("http://localhost:5173/spacing-lab", { waitUntil: "networkidle" });
    const pad = await page.$eval(".card", el => getComputedStyle(el).padding);
    console.log(w, pad);
  }
  await browser.close();
})();'
360 16px
768 20.6px
1280 28px

Значення виводу: padding плавно масштабується і досягає очікуваних меж при цільових ширинах.

Рішення: якщо значення прищеплені на min/max занадто рано, відкоригуйте preferred-формулу або інтерполяційний діапазон.

Завдання 5: Виявити зсуви макета (ризик CLS) на сторінках з великою кількістю відступів

cr0x@server:~$ node -e '
const { chromium } = require("playwright");
(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage({ viewport: { width: 1280, height: 900 }});
  await page.goto("http://localhost:5173/pricing", { waitUntil: "load" });
  await page.waitForTimeout(2000);
  const cls = await page.evaluate(() => new Promise(resolve => {
    let cls = 0;
    new PerformanceObserver(list => {
      for (const entry of list.getEntries()) if (!entry.hadRecentInput) cls += entry.value;
      resolve(cls);
    }).observe({ type: "layout-shift", buffered: true });
  }));
  console.log("CLS", cls);
  await browser.close();
})();'
CLS 0.02

Значення виводу: CLS низький; відступи навряд чи спричиняють помітні зсуви.

Рішення: якщо CLS зростає після зміни токенів відступів, шукайте пізнє підвантаження шрифтів або динамічний контент у поєднанні з флюїдними відступами.

Завдання 6: Підтвердити, що збірка CSS зберігає `clamp()`

cr0x@server:~$ npm run build
...
dist/assets/app.css  182.41 kB │ gzip: 28.11 kB

cr0x@server:~$ rg -n "clamp\(" dist/assets/app.css | head
1432:--space-4:clamp(1rem,.8rem + .8vw,1.6rem)

Значення виводу: ваш бандлер/мінімізатор не видалив і не переписав clamp некоректно.

Рішення: якщо clamp зникає або спотворюється, перевірте налаштування PostCSS/autoprefixer та будь-які трансформації «legacy CSS».

Завдання 7: Перевірити війни специфічності, що перевизначають токени

cr0x@server:~$ rg -n "\.card.*padding" src/styles
src/styles/components/card.css:5:.card { padding: var(--card-padding); }
src/styles/pages/checkout.css:88:.checkout .card { padding: 12px; }

Значення виводу: перевизначення на рівні сторінки затирають spacing компоненту.

Рішення: замінити page-override на семантичні токени контексту (наприклад, .checkout { --card-padding: ... }) замість хардкодів.

Завдання 8: Перевірити, що зміни кореневого розміру шрифту не ламають шкалу

cr0x@server:~$ node -e '
const { chromium } = require("playwright");
(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage({ viewport: { width: 768, height: 900 }});
  await page.goto("http://localhost:5173/spacing-lab");
  const normal = await page.$eval(".card", el => getComputedStyle(el).paddingTop);
  await page.addStyleTag({ content: ":root{font-size:20px}" });
  const bigger = await page.$eval(".card", el => getComputedStyle(el).paddingTop);
  console.log({ normal, bigger });
  await browser.close();
})();'
{ normal: '20.6px', bigger: '25.8px' }

Значення виводу: відступи зростають разом із розміром шрифту користувача. Зазвичай це добре для доступності.

Рішення: якщо це ламає макети, компоненти занадто тісні; перегляньте min/max або зафіксуйте деякі токени.

Завдання 9: Виявити несподівані зростання на ультрашироких моніторах

cr0x@server:~$ node -e '
const { chromium } = require("playwright");
(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  for (const w of [1440, 1920, 2560, 3840]) {
    await page.setViewportSize({ width: w, height: 900 });
    await page.goto("http://localhost:5173/spacing-lab");
    const pad = await page.$eval(".card", el => getComputedStyle(el).paddingTop);
    console.log(w, pad);
  }
  await browser.close();
})();'
1440 28px
1920 28px
2560 28px
3840 28px

Значення виводу: padding досягає max і лишається на ньому. Це «ніколи не сходити з розуму» працює.

Рішення: якщо відступ продовжує рости, ваш max занадто високий або відсутній; додайте max-границі для кожного токена з vw.

Завдання 10: Виявити невідповідне використання токенів у пакунках (реальність монорепо)

cr0x@server:~$ rg -n "--space-[0-9]" packages -S
packages/ui/src/tokens.css:7:--space-3: clamp(0.75rem, 0.60rem + 0.55vw, 1.10rem);
packages/marketing/src/spacing.css:7:--space-3: clamp(12px, 10px + 0.8vw, 18px);

Значення виводу: у вас кілька визначень одного й того самого імені токена з різною семантикою. Це часовий вибух.

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

Завдання 11: Підтвердити, що експорт дизайн-токенів не квантує значення

cr0x@server:~$ jq '.tokens.spacing' dist/design-tokens.json | head
{
  "space-1": "clamp(0.25rem, 0.20rem + 0.20vw, 0.40rem)",
  "space-2": "clamp(0.50rem, 0.40rem + 0.35vw, 0.75rem)"
}

Значення виводу: ваш конвеєр токенів зберіг точні рядкові значення, не округливши їх у фіксовані px.

Рішення: якщо значення конвертовано в px, виправте експортер/транспайлер; флюїдна система відступів помирає, коли токени стають статичними.

Завдання 12: Обмежувач у CI: провал, якщо новий компонент додає сирий px у відступи

cr0x@server:~$ cat /tmp/check-spacing.sh
#!/usr/bin/env bash
set -euo pipefail
if rg -n "(padding|margin|gap)\s*:\s*[0-9]+px" src/styles/components; then
  echo "ERROR: raw px spacing found in components. Use spacing tokens."
  exit 1
fi
echo "OK: no raw px spacing in components."

cr0x@server:~$ bash /tmp/check-spacing.sh
OK: no raw px spacing in components.

Значення виводу: ваш шар компонентів поважає систему токенів.

Рішення: якщо скрипт падає, або рефактор компонент, або задокументуй виняток з коментарем і придушенням лінта (рідко).

Завдання 13: Переконатися, що порядок min/max правильний (немає інвертованих clamp)

cr0x@server:~$ rg -n "clamp\([^,]+,[^,]+,[^)]*\)" src/styles/tokens/spacing.css
4:  --space-1: clamp(0.25rem, 0.20rem + 0.20vw, 0.40rem);

cr0x@server:~$ node -e '
const fs = require("fs");
const css = fs.readFileSync("src/styles/tokens/spacing.css","utf8");
const re = /clamp\(([^,]+),([^,]+),([^)]+)\)/g;
let m;
while ((m = re.exec(css))) {
  const [_, min, mid, max] = m;
  if (min.includes("vw") || max.includes("vw")) continue;
  console.log("CHECK", min.trim(), "|", mid.trim(), "|", max.trim());
}'
CHECK 0.25rem | 0.20rem + 0.20vw | 0.40rem

Значення виводу: можете прицільно перевірити інвертовані min/max або безглузді мікси. Скрипт грубий; для гардрейлів це нормально.

Рішення: якщо знаходите інверсії (max менший за min), виправте негайно; вони дають clamp-значення, що не масштабуються як треба.

Завдання 14: Дим-тест відчуття відступів з golden-сторінкою та скриншот-дифами

cr0x@server:~$ node -e '
const { chromium } = require("playwright");
(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  for (const w of [360, 768, 1280]) {
    await page.setViewportSize({ width: w, height: 900 });
    await page.goto("http://localhost:5173/spacing-lab", { waitUntil: "networkidle" });
    await page.screenshot({ path: `artifacts/spacing-lab-${w}.png`, fullPage: true });
    console.log("wrote", `artifacts/spacing-lab-${w}.png`);
  }
  await browser.close();
})();'
wrote artifacts/spacing-lab-360.png
wrote artifacts/spacing-lab-768.png
wrote artifacts/spacing-lab-1280.png

Значення виводу: у вас є детерміновані артефакти для рев’ю і CI-дифів.

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

Поширені помилки (симптом → корінь → виправлення)

1) Симптом: відступи ніколи не змінюються при зміні розміру вікна

Корінь: preferred-значення завжди нижче min або вище max, тож clamp «приклеює» значення.

Виправлення: відкоригуйте preferred-формулу або розширте діапазон інтерполяції; перевірте обчислені значення на 3–4 ширинах.

2) Симптом: відступи вибухають на великих моніторах

Корінь: токен використовує vw без осмисленого max або max занадто великий.

Виправлення: додайте строгі max-границі для кожного токена, що залежить від viewport; також обмежте ширину контенту контейнером.

3) Симптом: відчуття відступів непослідовне між сторінками

Корінь: CSS на рівні сторінки перевизначає padding/margin сирими значеннями, обходячи токени.

Виправлення: введіть контекстні семантичні токени (встановлюйте кастомні властивості на корені сторінки) замість переозначень компонентів.

4) Симптом: масштабування для доступності ламає макети

Корінь: мікс px- і rem-основних відступів спричиняє нерівномірне масштабування; компоненти були спроектовані занадто щільно.

Виправлення: використовуйте rem для min/max; тестуйте зі збільшеним кореневим шрифтом; збільшіть min або дозвольте перенесення рядків.

5) Симптом: «випадковий» додатковий простір у стекових макетах

Корінь: margin у дітей комбінується з gap, або ви все ще використовуєте margin-based stacking.

Виправлення: стандартизуйте на утилітах стеків з gap; видаліть маргін-дітей у стекових контекстах.

6) Симптом: відступи відрізняються між Chrome і Safari

Корінь: відмінності округлення в субпіксельних обчисленнях; шрифти також можуть впливати на сприйняття відступів.

Виправлення: прийміть невеликі округлювальні відмінності; уникайте надтонких кроків токенів; перевіряйте скриншоти на ключових ширинах.

7) Симптом: токени є, але команди їх не використовують

Корінь: забагато токенів, незрозумілі імена або відсутність примусу.

Виправлення: тримайте примітиви на ~8 кроках; надавайте семантичні псевдоніми; додайте CI-обмеження для сирих px у компонентах.

8) Симптом: редизайн вимагає змін сотень файлів

Корінь: компоненти посилаються напряму на примітиви замість семантичних токенів.

Виправлення: мігруйте компоненти на семантичні токени (--card-padding, --section-padding-y), змеплені на примітиви.

Чеклісти / покроковий план

Покроково: безпечно впровадити систему відступів на основі clamp

Оберіть підтримуваний діапазон.
Визначте ключові ширини, які вам важливі (наприклад, 360, 768, 1280). Запишіть їх у репозиторії.
Створіть 6–8 примітивних токенів.
Почніть з --space-1…--space-8. Утримайтесь від спокуси створити --space-13.
Додайте семантичні псевдоніми.
Визначте --page-gutter, --card-padding, --stack-gap, --form-row-gap.
Рефакторіть один патерн макета за раз.
Почніть з гутерів сторінки і ширини контейнера. Це дає негайну узгодженість.
Прийміть gap для стеків.
Замініть margin-based стекування в новому коді спочатку. Потім мігруйте старий код поступово.
Створіть spacing lab-сторінку.
Відрендеріть набір репрезентативних компонентів; зробіть її зручною для перегляду на кількох ширинах.
Додайте скриншот-дифи в CI.
Виберіть 3 ширини і одну тему (світла/темна за потреби). Тримайте її стабільною і нудною.
Впровадьте обмежувачі.
CI-перевірки на наявність сирого px у CSS компонентів. Винятки лише з обґрунтуванням.
Проганяйте перевірки доступності.
Тестуйте збільшений розмір шрифта і масштабування. Переконайтесь, що перенесення рядків працює; уникайте фіксованих висот, що припускають один рядок.
Задокументуйте «як обирати токен».
Короткий внутрішній документ кращий за список токенів. Поясніть намір: «space-2 — щільно, space-4 — комфортно» тощо.

Операційний чекліст: перед злиттям зміни токена

Обчислені значення перевірені на 3 ширинах для впливових токенів
Скриншоти spacing lab переглянуті (diffs мають сенс)
Жодних нових хардкодів на рівні сторінки не додано
Перевірка при масштабуванні/зміні кореневого шрифту виконана (хоча б раз за реліз)
Перевірені max-границі, щоб уникнути вибуху на ультрашироких екранах

FAQ

1) У чому зберігати токени відступів: px, rem чи щось інше?

Використовуйте rem для min/max, щоб відступи враховували налаштування шрифту користувача. Для preferred використовуйте
vw (або мікс у calc()). Уникайте систем тільки на px, хіба що ви робите кіоск з контрольованими дисплеями.

2) Чи потрібні брейкпоінти, якщо я використовую `clamp()`?

Їх потрібно менше. Брейкпоінти все ще корисні для перепотоку макета (зміни навігації, кількостей колонок), але відступи часто можна робити
флюїдними без них.

3) Скільки кроків відступів мені потрібно?

Шість-вісім примітивів зазвичай достатньо. Якщо команди постійно просять «щось поміж», ймовірно, потрібні кращі семантичні псевдоніми, а не більше примітивів.

4) Чи можна використовувати `clamp()` для від’ємних margin?

Можна, але обережно. Від’ємні margin — структурні хаки; флюїдні від’ємні margin — хаки, що змінюються з вьюпортом.
Якщо мусите, обмежте їх жорстко і ретельно тестуйте.

5) Що краще: флюїдна поведінка на вьюпорті чи на контейнері?

Контейнерна поведінка коректніша для бібліотек компонентів, вбудованих у різні макети. Вьюпорт-навантажена — простіша і часто достатня
для гутерів сторінки та глобальних відступів. Багато систем використовують обидва підходи: вьюпорт для структури сторінки, контейнерні запити — для компонентів.

6) Чому мій `clamp()` здається, що змінюється занадто повільно?

Ваш нахил (коефіцієнт vw) занадто малий або min/max занадто близько. Оберіть ширші межі або збільште vw-термін — але завжди обмежуйте max.

7) Чому відступи здаються непослідовними навіть з токенами?

Тому що відступи відносні. Картка з --space-4 поруч із секцією з --space-7 може виглядати неправильно, якщо
типографіка і ширини контейнерів не відповідають. Системи токенів зменшують випадковість, а не ухвалюють рішення за вас.

8) Чи погіршує використання `clamp()` продуктивність?

Ні в істотному сенсі для типових додатків. Більші ризики продуктивності — це треш на рендерінгу від JS, важкі шрифти і великий DOM.
Тримайте CSS простим і уникайте перерахунків inline-стилів на ресайзі.

9) Як переконати команду, що любить піксельну точність?

Покажіть їм один і той самий компонент у п’яти ширинах порівняно: кроки брейкпоінтів проти флюїдності clamp. Піксельна точність на трьох ширинах
все одно помилкова на інших тисячах. Використовуйте скриншот-дифи як нейтрального суддю.

10) Токени мають бути лінійними (строге відношення) чи вручну налаштованими?

Вручну налаштовані в розумних межах. Строге відношення гарно на папері, але часто невірно в UI: малі відступи потребують тоншої градації,
великі — можуть стрибати більше. Оптимізуйте під відчуття в реальних макетах.

Наступні кроки, які можна зробити цього тижня

Якщо ви хочете систему плавних відступів, що переживе контакт з продакшеном, зробіть ці кроки в порядку:

Створіть 6–8 clamp-based примітивів відступів з жорсткими max-границями. Покладіть їх в один файл. Перестаньте розкидати формули.
Додайте семантичні токени для топ-5 потреб padding/gap (page gutter, card padding, section padding, stack gap, form gap).
Побудуйте spacing lab-сторінку і підключіть її до скриншот-дифів на трьох ширинах. Зробіть це частиною звичайної роботи, а не подією.
Додайте гардрейл у CI, який відмічає нові сирі px у стилях компонентів.
Прогоніть швидкий план діагностики на одній «проблемній сторінці» і рефакторіть найгірші місця першими: page overrides, margin стеки, відсутні max-границі.

Плавні відступи з clamp() — це не про те, щоб бути химерним. Це про те, щоб прибрати категорію багів у макеті і зробити зміни безпечнішими.
Ви будуєте невелику частину інфраструктури. Трактуйте її так, неначе вона має ротацію on-call — бо має.