#css_in_action
Навіть у 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

Я тут планую записати нову співбесіду для Ютубу. В ідеалі цей випуск виглядав би так:

— Відважний трейні або сміливий джуніор. А ще краще — відважна трейні чи смілива джуніорка.

— Формат — вайбкод-рев'ю. Я даю задачу і півтори години на її реалізацію перед записом. На зйомці — захист. Зараз це дуже важлива навичка для інженерів, що використовують LLM для роботи — розуміти і вміти розібратися в чужому коді.

— Хотів би зняти випуск наступного або тамтого тижня.

Відчуваєте, що це саме ваша нагода спозоритись на весь інтернет? Заповніть формочку:

https://forms.gle/ytgXa619bE8xy1mBA

#збір_на_РЕБ
Товариство, прийшов час нового збору для ЗСУ.
Цього разу нашої допомоги попросили в 115 ОМБр 3МБ.

Ми збираємо на засіб радіоелектронної боротьби "Писець" та приладдя до нього.
Наразі мета збору — 300 000 грн.

Дякую за кожну гривню! Разом ми робимо великі речі!

🔗Посилання на банку
https://send.monobank.ua/jar/46FX59UkXS

💳Номер картки банки
4874100026432743

P.S. Розіграш за минулий збір для ЖВІ вже проведено, і артбук поїхав до нового власника. А в коментарях до допису додам скрин з підтвердженням, що стоматкабінет вже працює на повну.

#нове_відео
Товариство, запрошую до перегляду нового випуску "Подкасту у нас вдома". Цього разу розмовляв з Уляною Білінською-Шутою — QA-менторкою й тестувальницею з досвідом роботи в Uber та LinkedIn.

Говорили про усяке — де добре, де не дуже, хто наші конкуренти на закордонних ринках, які внутрішні тємки є в великих компаніях, і чи взагалі є шанс для українців працювати на американське ІТ.

Приємного перегляду!

З вас комент під відео, вподобайка і поширення. Дякую!

https://youtu.be/yyoNw2g2VHM

Дякую за довіру та підтримку, товариство!

Доброго ранку, товариство! За вікном чудова погода, співають пташечки і світить сонечко. Виглядає як чудовий початок тижня.

Маю до вас дві справи.

Перша: нагадую про збір на РЕБ для 115ОМБр, наразі є 29 500 грн з 300 000. Кожна гривня важлива, і за кожну гривню я вдячний надзвичайно.

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

Тому пропоную вам написати в коментарях, про що вам цікаво було б почитати цього тижня: щось про HTML чи CSS, може якісь роздуми, може десятитисячний допис про ШІ.

Загалом, прошу ділитися своїми побажаннями!

І гарного усім дня ;)

Кнопка.

Будьмо відверті — мало хто з нас сприймає елемент <button> інакше, ніж просто засіб запуску якогось коду по кліку. І саме тому багато хто не бачить і різниці між кнопкою й просто дівом з addEventListener. А це, в свою чергу, призводить до хибного бачення <button> як просто клікалки з тупими стилями за замовчанням.

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

Якщо не зважати на це уваги, розробники рано чи пізно починають займатися "цікавими дослідами" і городити те, що має бути простою кнопкою, за допомогою дівів чи спанів. А іноді — десятків дівів чи спанів. Тут примітно, що насправді дуже легко знехтувати саме <button>, адже на поверхні ми бачимо лише блок, який треба натиснути. І це чудово вміють усі інші елементи: навісимо onClick чи що у вас там у вашому улюбленому фреймворку, і задача ніби вирішується.

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

Взагалі, я раджу завжди ставити собі питання — чи є вже в бравзері те, що я намагаюсь зробити? Відверто, в більшості випадків відповідь однозначна — так. Звичайно, я розумію, що навіть зараз багато нативних контролів у бравзері не надають достатніх засобів для такої стилізації, яку часто вигадують наші любі дизайнери. Чи такого функціоналу, який вигадують наші любі стейхолдери.

І це підіймає доволі цікавий аспект розробки — ми часто сприймаємо інтерактивні елементи через призму того, як вони виглядають, а не що вони роблять. Несвідомо в такий спосіб ми жертвуємо і ефективністю інтерфейсу, і зручністю розробки. Бо замість того, аби узяти те, що вже працює і так, нам доводиться вигадувати колесо заново. Або кнопку.

<button> в цій історії є дуже цікавим прикладом, бо цей елемент або ігнорують, або використовують замість усього, що бодай якось клікається. Так, я про <a> в якості кнопки і <button> в якості гіперпосилань. Повірте, я таке бачив на власні очі.

Я спеціально не говорю про поведінку <button> в формах в цьому дописі, бо планую детальніше зупинитися на цій темі у наступному. Чому перезавантажується сторінка, якщо натиснути в кнопку всередині форми, чим це зумовлено, чому це не баг, і як зробити так, щоб цього не відбувалося — про це наступного разу.

А сьогодні були просто ліричні роздуми про елемент <button> і його роль в ширшій картині Всесвіту.

Просто запамʼятайте — якщо, дивлячись на дизайн, у вас виникає підсвідоме бажання тицьнути в щось мишкою, то швидше за все це звичайна кнопка, а не оріґамі з <div>.

@babichdev

Збір на РЕБ для 115 ОМБр — кожна гривня важлива!

#html_in_action
Здається, що <button> існував завжди. Відверто, з точки зору більшости веброзробників, так і є. Цей тег зʼявився в специфікації HTML 4.0 1997 року, і старший за багатьох з моїх любих читачів.

А ще ми нерозривно повʼязуємо його з формами, адже як іще можна надіслати дані з нашої сторінки, як не за допомогою <button>? І ось ці два моменти часто складаються в хибну думку, що кнопки зʼявилися в HTML разом з формами, і є їхньою невідʼємною частиною. Чому ж ця думка хибна?

Річ у тім, що форми випереджають <button> на цілих два роки і дві версії HTML: вони зʼявляються в стандарті HTML 2.0 від 1995 року. І це вже спростовує другу тезу про невідʼємність кнопки від форми.

А як же так сталося, і як відправлялися форми в той час? Дуже просто — input. Кнопки як окремого примітива чи сутності не було, а бідолашний інпут віддувався за все, що не було select чи textarea. І саме тоді й зʼявилися різні типи інпутів, серед яких були й submit, reset та button.

До речі, про reset я й сам чи то не знав, чи то забув до цього часу. Він, виявляється, скидає стан форми до значень за замовчуванням.

input цілком собі вдало виконував функції кнопки, але button, як я зазначив на початку, досить швидко зʼявився в специфікації. Не братимусь розбирати причини, але вони, як на мене, доволі очевидні з різниці між інпутом і кнопкою.

Якщо дуже стисло окреслити різницю між button та input, то всередину button можна додавати розмітку, а всередину input — не можна.

Тепер поглянемо на типи: submit, reset, button.

submit є значенням атрибуту type за замовчуванням, і саме тому будь-яка кнопка без явного значення цього атрибуту, поміщена всередину форми, буде її "сабмітити". Я певен, що кожен з нас бодай раз стикався з цією поведінкою, і Ґуґл памʼятає саме ваш запит "button form prevent submit".

Я памʼятаю, наскільки це дратувало. Але зараз розумію, що це роздратування насправді було викликано не якоюсь не такою поведінкою кнопки, а саме моїм незнанням та нерозумінням, як вона насправді працює.

Виправити таку поведінку дуже просто — явно вказати type="button". І тоді наша кнопка перетвориться на… кнопку-кнопку. Саме той інтерактивний примітив, про який я говорив минулого разу. В цьому випадку бравзер прибирає з кнопки "очікувану" поведінку в контексті форм. Якщо простіше, то кнопка більше не сабмітить.

Про type="reset" я вже побіжно згадав, і тут немає ніяких підводних каменів — просто скидання стану до початкових значень.

Є ще один цікавий момент, про який я колись розповідав: кнопку можна звʼязати з формою через атрибут form, і тоді її можна розмістити поза нею, і все працюватиме. Так от. Виявляється, ця поведінка притаманна усім елементам форми, не лише кнопкам. Але я розберу цей курйоз іншим разом.

Тож, якщо підбити підсумки:
- Кнопки — логічне продовження інтерактивності, закладеної input;
- Мають три значення атрибуту type: submit, reset, button;
- За замовчуванням тип кнопки — submit;
- Якщо треба кнопка всередині форми, що має робити щось інше, то це type="button"

Але HTML не стоїть на місці, і сьогодні button вміє набагато більше, ніж сабмітити форму і бути безвольним гачком, до якого ми чіпляємо свої onClick.

Про що мова? Можливо, ви вже здогадалися, тож пишіть в коментарях. А я вже готую наступний допис.

MDN: button type

@babichdev

***
Збір на РЕБ для 115 ОМБр: зібрано 30 731 / 300 000грн. Долучайтесь!

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

— Допис про типи кнопок — https://t.iss.one/babichdev/347;
— Збір на РЕБ для 115 ОМБр — https://t.iss.one/babichdev/345

Перше можна виправити, поставивши серденько, друге — закинувши кілька гривень.

Дякую за увагу, всім гарного вечора!

#html_in_action
Тривалий час сценарій взаємодії з кнопкою був дуже простий — ми вішаємо event listener на натискання і "обробляємо" його — виконуємо якусь логіку, викликаємо якийсь функціонал чи змінюємо стан елементів. По суті, кнопка завжди виступала як ініціатор дії, але при цьому знала забагато про цю дію.

Зараз же зʼявилась можливість змінити цей підхід на декларативний в певних випадках. Мова йде про Invoker Commands API.

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

<button command="..." commandfor="..."></button>

Де command це імʼя команди, яку ми передаємо, а commandfor має відповідати id елемента, якому цю команду призначено. Ви вже могли бачити деякі приклади, наприклад, відкриття dialog через команду show-modal.

Це, насправді, одна з суттєвих переваг цього API — для вбудованих команд тепер не потрібен JS взагалі, як в тому ж прикладі з dialog.

Важливо зрозуміти, що обробка цих команд відбувається не на кнопці по натисканню, а саме на *target* — самим бравзером для вбудованих команд, або користувацьким кодом для кастомних команд. Це дещо інша парадигма, ніж звична нам обробка кліку. Тепер сам елемент відповідає за логіку всередині себе, а кнопка лише передає команду.

До речі, так, саме *передає* напряму, а не *транслює*. Одна кнопка може передати команду лише одному цільовому елементу. Тому, до речі, подія command не спливає, і викликається виключно на самому елементі.

І Invoker Commands API підтримує користувацькі команди, які визначаються через знайомий уже нам префікс --. Ось приклад:

<button command="--toggle" commandfor="target">
  TRIGGER
</button>
<p id="target">TARGET</p>

document
  .getElementById('target')
  .addEventListener('command', event => {
  if (event.command === '--toggle') {
    event.target.classList.toggle('foo')
  }
})

Демо на JSFiddle

Як бачимо, саме елемент параграфу відповідає за зміну свого стану, а кнопка лише передає команду в момент натискання. До речі, обʼєкт події тут — CommandEvent, а не PointerEvent. Окрім command можна дізнатися, хто саме відправив команду через властивість source.

Ми можемо мати скільки завгодно тригерів, але лише один цільовий елемент. Тобто нашим target може командувати безліч кнопок, але одна кнопка не може командувати більш ніж одним елементом. Звичайно, було б зручно саме транслювати команди в певних випадках, але поки як є. Можливо, згодом зʼявиться і така можливість.

Поки ж Invoker Commands API уже зробив надзвичайно важливу річ — надав можливість декларативного підходу для опису взаємодії з UI. Тепер control flow виглядає логічніше: ініціатор — ціль — намір, де обробка наміру відбувається саме ціллю.

Що дуже важливо — не варто сприймати це як "заміну" кліку. Також не варто відкидати це в сторону, бо "дуже мало вбудованих команд, нашо воно мені треба". Головна цінність Invoker Commands API саме у зміні парадигми того, як взаємодіють елементи інтерфейсу між собою у відповідь на дії користувача. Тобто ми передаємо обробку від кнопки до самого елемента.

І для цього цей API надає зручніші, простіші й логічніші інструменти.

До речі, ви вже пробували Invoker Commands API чи плануєте спробувати? Поділіться досвідом в коментарях.

P.S. Не буде вподобайок — не буде дописів. Я серйозно.

Що почитати:
MDN: Invoker Commands API

Що почитати душнілам:
WHATWG: "command" attribute
WHATWG: "commandfor" attribute

@babichdev

***
Збір на РЕБ для 115 ОМБр: 36_871 / 300_000грн

#думки_вголос
Що таке код-ревʼю і кому воно потрібне? Особливо сьогодні, в часи LLM, які прямо все-все можуть робити за нас.

Я стикався з різними підходами, які варіюються від "нафіг воно кому треба", "ревʼювить тільки тімлід" і до "поки не отримаєш тисячу зелених галочок, твої два рядочки в стейдж не попадуть".

З деякими я не погоджуюсь, деяким лишаю право на існування, деякі підтримую беззаперечно. І з плином часу мій цей розподіл змінюється. Але одне залишається постійним — я вважаю, що код-ревʼю необхідні і потрібні.

В першу чергу це спосіб не пропустити сумнівні рішення не лише в кодову базу, а й у голову автора. Адже схваливши такі пул-ріквести, ми прямо кажемо — "молодець, нам норм". І якщо таке рішення проходить раз, другий, то на третій автор уже буде впевнений, що його підходи до коду — правильні.

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

Це, певно, одна з найперших порад, які я даю щодо покращення процесу ревʼю — вчіться один у одного. Код-ревʼю це чудова нагода для цього.

Щодо LLM в код-ревʼю. Це прекрасний інструмент для визначення механічних хиб — потенційних багів чи відхилень від конвенцій. В цьому плані використання LLM не відрізняється від того ж лінтера чи ще якого статичного аналізатора. Усе, що може бути автоматизоване — має бути автоматизоване.

Але й повністю віддати на плечі алгоритму весь процес ревʼю мені не видається можливим. Він може покрити більшість речей, які можна формалізувати, а от відкриті до дискусій питання будуть приречені на довічне лімбо "це вже майже ідеальний варіант, але…". З LLM дуже важко сперечатися, воно завжди знайде до чого доколупатися. Навіть у рішеннях, запропонованих ним же.

Насправді, на мою думку, головна причина неможливості повної автоматизації код-ревʼю LLM — це відповідальність. У LLM її немає. "Так, дійсно, я пропустив цей PR. Хочеш, більше не буду його пропускати?".

Тому людське ревʼю має обовʼязково бути. Це засіб для обміну досвідом, для навчання, місце для дискусій й спільних рішень.

Хороше код-ревʼю має шукати відповідь на питання "Чому автор зробив саме так?". Не "чому тут let а не const", не "Boolean() vs ||", чи ще якесь технічне душнільство, яке має бути знайдено пайплайном. А саме "Чому автор обрав цей шлях?".

Хороше код-ревʼю заохочує. До дискусії, до обміну знаннями, до професійного росту.

Хороше код-ревʼю — спільна справа. Джуни мають ревʼювати техлідів, так само як і мідли — синьйорів. Одним словом — усі мають ревʼювати усіх.

Хороше код-ревʼю важко зробити. Погане — взагалі не вимагає зусиль. Тому я часто чую історії про те, що ревʼю проводить тільки техлід за попереднім записом, чи що джуни не ревʼювлять нікого, зате їх — усі. І так далі.

Код-ревʼю — це точка росту не лише для одного розробника, а й для усієї команди, продукту.

P.S. Цієї середи, до речі, відбудеться онлайн-зйомка "Вайбкод-ревʼю для трейні". Деталі згодом ;)

#коштозбір
Товариство, збір на РЕБ для 115 ОМБр триває.

Зібрано: 43 105 грн
Мета: 300 000 грн

🔗Посилання на банку
https://send.monobank.ua/jar/46FX59UkXS

💳Номер картки банки
4874100026432743

Громадо! 2 квітня робимо чергову лампову, і вже знаємо, що буде гаряче.
Двоє спікерів, обидва з темами про ШІ — але не з тими, де “ой які ми всі молодці, живемо в майбутньому”. А з тими, де чесно і в лоб.

Мирослав Танцюра розкаже, чому ШІ пише фігню — і чому це не його провина (спойлер: це наша).

Марк Абрагамович підніме тему, яку всі бояться обговорювати вголос — що відбувається з нашими навичками, поки ми радісно делегуємо все штучному інтелекту.

Формат як завжди — ніякого “сиди тихо і слухай”. Хочеш перебити — перебивай. Хочеш челенджити спікера — будь ласка, тільки будь готовий, що тобі теж прилетить. Без образ, але й без дипломатії.

І так — на цій зустрічі ми анонсуємо наступну лампу. Нова локація, новий формат, спонсори, подарунки, афтепаті на свіжому повітрі. Коротше, ми трохи підросли і хочемо показати, що з цього вийшло.

📅 2 квітня, двері о 18:00

📍 Львів, офіс Sigma Software

Приходь, якщо не боїшся думати вголос. Ну і якщо боїшся — тим більше приходь, ми тебе розговоримо.

Реєструйся ось тут за ціну менше смузі