Навіть у 2026 році люди не перестають дивуватися, що відносні (тобто відсоткові) вертикальні margin та padding насправді рахуються не від висоти, а від ширини (насправді ширини containing block) елемента). 100% розуміння, 0% засудження — свого часу для мене це теж стало неприємним відкриттям.
Тож чому так? Насправді, це один з моїх улюблених випадків, коли "так історично склалося". Той факт, що ця поведінка зафіксована в CSS2.1, не означає, що вона просто прийшла комусь в голову і її затвердили по приколу. Річ у тім, що цей документ значною мірою був радше не оновленим стандартом, а таким собі "зліпком" того, що коїлося в дивовижному світі веброзробки на той час. І саме така поведінка була вже усталеною.
Існує припущення, що причина полягає в доволі складних алгоритмах обрахунку загального макету, і це було свідоме спрощення. Зазвичай ширина елемента доступна раніше за його висоту, особливо в класичній флоу-моделі, де висота залежна від вмісту. І розрахунок вертикальних відступів від ширини дозволив уникнути зациклених обрахунків в ранніх рушіях.
Відверто, дуже багато речей, які здаються нелогічними чи незрозумілими в CSS, насправді спричинені ось такими непростими рішеннями, бо на світанку веброзробки доводилося шукати шляхи, аби обійти нестачу обчислювальних ресурсів та недосконалість алгоритмів. От такий hack driven development.
Попри те, що такий підхід досить контрінтуїтивний, він усе ж спромігся породити бодай одне непогане рішення (читай — хак): попередника aspect-ratio, що дозволяє втілити співвідношення сторін за допомогою вертикального падингу. Про нього я вже колись розповідав.
Тож якщо коротко — логічного пояснення цьому немає. Така поведінка зафіксована в специфікації, а пошук її істинних причин, відчуваю, може затягнути нас у пригоди, яким позаздрив би сам Індіана Джонс.
Але лишається відкритим питання — чи можемо ми усе ж задавати відносні відступи залежно від висоти? Відповідь — нуууууууу… майже.
Відносно самого елемента? Тверде ні. Відносно чогось іншого? До вибору, до кольору.
Як мінімум, тепер можна використовувати vh та dvh. Так, це відносно висоти вʼюпорту, і я не дуже уявляю, кому треба такий падинг чи маржин, але суть від того не змінюється — це відносна величина, яка рахується від потрібної нам вісі.
І, звичайно, сьогодні ми маємо контейнерні одиниці.
cqh, cqb, cqi, cqw. Цікавлять нас cqh — 1% від висоти контейнера, та cqb — 1% від блочного розміру. За замовчуванням ці напрямки співпадають, але є нюанси при зміні напрямку письма.Проте з
cq* одиницями є надзвичайно важливий момент — вони рахуються від найближчого query container, а не від безпосереднього батьківського елемента. Це, якщо спрощено. Взагалі, тема container queries доволі цікава, і беззаперечно потребує окремого допису. Що скажете?Однак на даний момент саме container query units виглядають як найбільш надійний спосіб вирішити давню проблему — задавати вертикальні відступи відносно вертикальної вісі. І щодо підтримки перейматись не варто, згідно Can I Use це майже 95% сучасних бравзерів.
Взагалі, оця історія з відносними відступами чудово ілюструє те, як розвивається веб в цілому: обмеження стає домовленістю, домовленість породжує хаки, хаки стають поширеною практикою, а з часом вже платформа реагує та пропонує нове рішення у відповідь.
Хотів би написати "…рішення, що робить хак непотрібним", але ми усі розуміємо, що це не так. В деяких випадках, як з aspect-ratio, хак дійсно розчиняється в небутті, але часто, як із
cq* одиницями, ми отримуємо рішення, що лише частково закриває початкову проблему. Але при цьому — дозволяє вирішити ще низку проблем, про які ми й не здогадувались.Що почитати:
MDN — Layout and the containing block
MDN — padding
MDN — CSS container queries
Що почитати душнілам:
W3C — CSS 2.2 Box model
W3C — CSS Containment Module Level 3
@babichdev