IT forum Ukraine

07.03.2026

Настав час визнати: старі підходи до верстки вмирають. Ми переходимо до компонентно-орієнтованого CSS. Ось ключові технології, які змінили все:


Container Queries нарешті дозволили нам робити компоненти, які самі знають, як виглядати в будь-якому контейнері, без прив'язки до ширини екрану. Як ви ставитесь до цього стеку?

Liona, все це звучить круто на папері, але як щодо підтримки в Legacy-системах? Ми досі маємо клієнтів на застарілих версіях Edge та Chrome. @container — це круто, але Media Queries працюють усюди.

Підтримую Ендрю. А щодо @layer — це взагалі інший рівень болю. Тепер замість того, щоб просто глянути специфічність, треба шукати, в якому шарі прописаний стиль. Це перескладнює CSS там, де він мав бути простим.

Хлопці, вже 2026 рік! Поліфіли та Baseline 2024/2025 вже давно закрили питання підтримки. @layer навпаки прибирає 'війни !important'. Це інструмент для дорослої розробки, а не для лендінгів на 50 рядків.

Про 'війни !important' згоден, але :has()? Ви бачили, що воно робить з продуктивністю на дуже великих сторінках? Браузеру доводиться перераховувати дерево кожного разу, коли дитина змінює стан.

Саме так. І subgrid... Так, він вирішує проблему вирівнювання заголовків у картках, але чи не простіше просто використати Flexbox або JS-обчислення? Навіщо тягнути складні CSS-специфікації?

JS-обчислення для верстки? Це ж антипатерн! Subgrid робить це нативно і швидко. А продуктивність :has() в сучасних рушіях вже давно оптимізована. Ви просто боїтеся нового.

Ми не боїмося, ми прагматичні. Temporal API — от це реально корисна штука, бо Date в JS був жахом. Але CSS стає занадто 'розумним'. Скоро нам знадобляться IDE з дебагером саме для CSS-логіки.

До речі, @container вложеність може призвести до циклічних залежностей, якщо не бути обережним. Компонент міняє розмір контейнера, який міняє компонент...

Для цього є специфікація containment, яка це запобігає. Якщо ви професіонал, ви повинні знати ці нюанси, а не відмовлятися від прогресу.