HTML та CSS

Дванадцять симптомів і правило за кожним

Спершу таблиця, бо саме через це найчастіше відкривають сторінку про HTML і CSS: щось на екрані робить не те, що написано в коді. Кожен рядок — це симптом, який видно, правило, що його спричиняє, і виправлення. Жоден із дванадцяти не є багом браузера. Кожен — це правило, яке існувало завжди й зустріло код людини, що з ним ще не стикалася, — а правил так мало, що решта сторінки охоплює їх усі.

Що браузер робить із двома файлами

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

Спершу розбір. HTML стає DOM — деревом об’єктів, по одному на елемент, які скрипти можуть читати й змінювати. CSS стає CSSOM — тими самими правилами, перетвореними на об’єкти, до яких браузер може звертатися. Далі по черзі йдуть чотири кроки. Стилі обходять DOM і для кожного елемента та кожної властивості запускають каскад, щоб обрати одне значення. Розкладка бере ці значення й обчислює розмір і позицію кожного бокса. Відмальовка заповнює пікселі шар за шаром у порядку накладання. Композиція складає намальовані шари на екрані — зазвичай на GPUGPUGraphics Processing Unit — процесор для паралельних обчисленьПроцесор із тисяч простих ядер, які роблять однакову операцію над великими масивами чисел одночасно. Саме така будова потрібна для тренування й запуску моделей — тому GPU давно перестали стосуватися лише графіки.Усі терміни.

Гілка праворуч на діаграмі — та, про яку більшість людей ніколи не чує. Поряд із DOM браузер будує дерево доступності, у якому кожен вузол має роль, ім’я, стан і дії, які підтримує. Зчитувачі екрана, голосове керування й шар доступності операційної системи читають саме це дерево, а будується воно лише з HTML. Жоден CSS до нього не дістається. <div>, стилізований точнісінько під кнопку, у цьому дереві — просто шматок тексту.

HTML — це набір обіцянок

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

Діаграма — це весь аргумент в одному кадрі. Семантичні елементи кладуть у дерево доступності правильну роль, ім’я й стан без жодного рядка коду; <div> не кладе нічого, і кожен бракуючий шматок доводиться повертати атрибутами ARIAARIAAccessible Rich Internet Applications — атрибути доступностіНабір атрибутів HTML — role, aria-label, aria-expanded та інші, — що кажуть допоміжним технологіям, чим є елемент і в якому він стані. Він лише описує й нічого не реалізує: role="button" змусить зчитувач екрана оголосити кнопку, а елемент і далі ігноруватиме клавіатуру, доки ви не напишете цей код самі.Усі терміни та JavaScript. Здебільшого вибір стоїть не між двома способами зробити кнопку. Він між тим, щоб узяти кнопку, яку браузер уже зробив, і тим, щоб переробити її гірше.

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

Дві звички дають більшу частину практичної користі. Заголовки мають описувати структуру документа, а не кегль тексту: багато людей переміщуються сторінкою, стрибаючи між заголовками, і сторінка, чий єдиний <h1> — це логотип, не дає їм нічого. І кожен елемент форми потребує пов’язаного <label>; плейсхолдер лейблом не є, бо зникає саме тоді, коли потрібен, і часто взагалі не озвучується. Поруч із ними стоїть один атрибут: елемент <html> потребує lang, бо за ним зчитувач екрана обирає голос і вимову, — а 13,5% головних сторінок мільйона найпопулярніших сайтів досі його не мають.

Каскад — це алгоритм

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

Шари каскаду варто брати передусім з однієї причини: вони відділяють «наскільки сильно це має вигравати» від «наскільки точно це вибирає». Покладіть сторонній стиль у ранній шар, а власні перевизначення — у пізніший, і потреба нарощувати селектори зникне зовсім: один клас у пізнішому шарі переможе id у ранішому, бо другі ворота вирішуються раніше за треті. Шари працюють в усіх основних браузерах з початку 2022 року, тож причини їх не брати вже немає.

Дві речі плутають із каскадом. Перша — успадкування: кілька властивостей — серед них color, font-family і line-height — передаються від батька до дитини, якщо їх ніхто не задав, а більшість — margin, border, width — не передаються ніколи. Елемент із хибним кольором без жодного власного правила не програє каскад: у ньому нічого немає, і він успадковує. Друга — пара селекторів, що змінюють специфічність навмисно. :where() обгортає селектор і дає йому нульову специфічність — так бібліотека постачає стилі за замовчуванням, які можна перебити одним класом. :is() бере специфічність свого найспецифічнішого аргументу — так невинний на вигляд селектор раптом перемагає.

Спершу бокс, потім розкладка

Кожен елемент, який розкладає браузер, — це прямокутник із чотирьох шарів: вміст, внутрішній відступ (падінг) навколо нього, рамка й зовнішній відступ (маржин) поза рамкою. Дві умовності цієї моделі дають два рядки таблиці. Перша: width задає ширину самого лише вмісту, тож падінг і рамка додаються зверху, — це рядок 3, і саме тому майже кожен набір стилів починається з box-sizing: border-box, де width означає весь бокс. Друга: вертикальні маржини між блоками в нормальному потоці схлопуються — 24 пікселі під одним абзацом і 16 над наступним дають проміжок 24, а не 40. Це рядок 4. Так задумано, щоб суцільний текст мав рівні інтервали, і стається це лише в нормальному потоці, ніколи між flex- чи grid-елементами.

До будь-якої системи розкладки існує нормальний потік — поведінка документа взагалі без CSS. Блокові елементи складаються вниз сторінкою й займають доступну ширину; рядкові стоять уздовж рядка й переносяться. Чимало коду розкладки існує, щоб відтворити те, що нормальний потік уже робив, а найдешевша розкладка — та, якої ви не написали.

Правило вибору коротке: якщо ви шикуєте речі вздовж однієї лінії і розміри має визначати вміст — беріть flex; якщо ви задаєте структуру, у яку падає вміст, — беріть grid. Вони вільно поєднуються: сторінка на grid із flex усередині кожної клітинки — звичайний випадок, а суперечка про те, що «краще», дорівнює суперечці, чи молоток перемагає пилку.

Одну умовність flex варто знати на ім’я, бо вона дає рядок 5. Мінімальна ширина flex-елемента дорівнює його вмісту, тож елемент відмовляється стискатися вужче за найдовше неподільне слово чи адресу й натомість виштовхується з контейнера. min-width: 0 дозволяє йому стиснутися. У grid та сама пастка, записана інакше, і те саме лікування — minmax(0, 1fr).

Позиціювання й накладання

Позиціювання виймає елемент зі звичайної розкладки, і кожен варіант визначається відносно чогось. relative зсуває елемент від місця, де він мав би бути, і лишає це місце за ним. absolute ставить його відносно найближчого предка, який сам позиціонований, — а коли такого немає, відносно сторінки: це рядок 8. fixed ставить його відносно вікна перегляду. sticky поводиться звичайно, доки контейнер прокрутки не почне виносити його з поля зору, а тоді тримає на місці, — і контейнер прокрутки — це найближчий предок із заданим overflow; ось чому випадковий overflow: hidden на три рівні вище — звична причина рядка 7.

Далі — що малюється поверх чого. z-index — це не глобальний рейтинг. Він упорядковує елементи всередині контексту накладання, а новий контекст створюється непомітно: позиціонованим елементом із z-index, але також opacity менше 1, будь-яким transform, filter чи isolation: isolate. Усе всередині контексту малюється разом, як одне ціле, на тому місці в порядку, яке займає його батько.

Що прибрав сучасний CSS

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

• Користувацькі властивості (--gap) — це справжні значення, які браузер обчислює під час роботи, тож вони каскадуються, реагують на медіазапити й читаються та задаються з JavaScript — на відміну від змінних препроцесора, яких на момент читання файлу браузером уже немає.
• Вкладення правил у правила працює в чистому CSS, в усіх основних браузерах з 2023 року, — це одна з останніх причин, через які малому проєкту взагалі був потрібен препроцесор.
• clamp() замінює більшість типографських шкал на брейкпоінтах: одне оголошення задає мінімум, плавну середину й максимум.
• Контейнерні запити дозволяють компоненту реагувати на ширину власного контейнера, а не вікна, — а саме цього багаторазовому компоненту й бракувало весь час.
• :has() вибирає батька за тим, що в ньому лежить, — той «батьківський селектор», який два десятиліття вважали неможливим.
• aspect-ratio резервує форму бокса ще до появи вмісту — це відправляє на пенсію хак із відсотковим падінгом і запобігає рядку 9 для кожного вбудованого відео.
• Одиниці svh, lvh і dvh описують екран телефона з показаною панеллю браузера, зі схованою або такою, як вона є зараз, — це виправлення рядка 10.
• Логічні властивості (margin-inline, padding-block) описують напрям відносно режиму письма, тож розкладка працює в мові справа наліво без дзеркального набору стилів.
• gap працює і в flexbox, і в grid, і це прибирає останню причину вішати відступи на дітей, а потім знімати їх у першої чи останньої.

Що насправді коштує користувачеві

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

Смуги під діаграмою конвеєра — друга половина історії. Зміна властивості перезапускає конвеєр із першого кроку, на який ця властивість впливає, а під час анімації цей перезапуск стається шістдесят разів на секунду й частіше:

У цьому все пояснення рядка 11. transform і opacity може опрацювати сама лише композиція — за умови, що елемент лежить на власному шарі, а для всього анімованого браузери влаштовують це самі, — тож анімація на них лишається плавною, навіть коли головний потік зайнятий чимось іншим. Той самий виїзд, написаний через left, запускає розкладку для елемента й усього навколо нього на кожному кадрі.

Два видимі збої варто назвати, бо обидва дешево попередити. Зсув розкладки — рядок 9 — стається, коли вміст приходить без зарезервованого місця: зображення без розмірів, шрифт, що підмінюється на інший за метрикою, рекламний блок, що виникає над тим, що людина читає. Google вимірює це як CLS — один із трьох Core Web VitalsCore Web Vitalsметрики досвіду сторінки від GoogleТри вимірювання, які Google бере з браузерів реальних відвідувачів: LCP — як швидко з’являється основний вміст; INP — як швидко сторінка відповідає на дії; CLS — наскільки стрибає розкладка. Вони впливають на ранжування в пошуку, але лише як один сигнал із багатьох: швидка сторінка, яку нема сенсу читати, однаково програє повільній, що відповідає на питання.Усі терміни, які з 2021 року враховує в ранжуванні, — і вважає показник понад 0,1 таким, що потребує покращення. Зарезервуйте місце — і цього не буде. А «биття» розкладки стається, коли JavaScript у циклі читає геометричну властивість, пише стиль і читає знову, змушуючи браузер синхронно перераховувати розкладку на кожній ітерації; групуйте спершу читання, потім записи.

П’ять кейсів і те, чого в кожному бракувало

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

Domino’s — той самий провал через десятиліття, коли юридичне питання вже вирішено. Ґільєрмо Роблес, незрячий, не зміг замовити піцу через сайт чи застосунок зі зчитувачем екрана й у 2016 році подав позов. У січні 2019 року Апеляційний суд дев’ятого округу постановив, що закон про права людей з інвалідністю (ADA) поширюється на сайт і застосунок компанії, коли вони пов’язані з її фізичними закладами, а в жовтні 2019 року Верховний суд США відмовився розглядати апеляцію Domino’s. Відтоді недоступне оформлення замовлення в США — це юридичний ризик, а не пункт беклогу. WebAIM Million показує, наскільки практика від цього далека: лютневе сканування 2026 року, що охопило мільйон головних сторінок, знайшло порушення WCAGWCAGWeb Content Accessibility Guidelines — стандарт доступностіСтандарт W3C про те, як зробити вебвміст придатним для людей з інвалідністю, записаний як перевірні критерії успіху трьох рівнів — A, AA і AAA. Саме на AA зазвичай посилаються закони й контракти, а відповідати йому на папері — не те саме, що незряча людина, яка змогла пройти ваше оформлення замовлення.Усі терміни на 95,9% із них, а 96% усіх помилок припали на шість категорій — низькоконтрастний текст, відсутній alt, поля форм без лейблів, порожні посилання, порожні кнопки й відсутній lang. Кожна з шести — умовність, яку ця сторінка вже описала.

Щоб купити ту саму властивість, їхній інструментарій не потрібен. Стилі стають непідтримуваними майже ніколи не через розмір. Причина в тому, що ніхто не може передбачити, що зламає видалення правила, — а це стається, коли селектори тягнуться через межі компонентів: правило у файлі шапки стилізує щось у підвалі, бо обидва підпали під .card h3. Хоч би яку методологію ви взяли, щоб цьому запобігти, — конвенцію імен, CSS-модулі, скоуповані стилі у фреймворку чи шари плюс дисципліну, — властивість, яку ви купуєте, та сама: локальність, щоб зміна лишалася там, де ви її зробили.

Останній рядок — кейс іншого роду: рішення платформи, а не помилка команди. Мобільні браузери визначили 100vh як висоту зі схованою адресною панеллю, тож роками кожен повноекранний банер був вищим за екран, на якому відкривався, а обхідними шляхами були скрипти, що вимірювали вікно. CSS виправив це в корені трьома одиницями — svh, lvh, dvh, — які з’явилися в Safari в березні 2022 року і в Chrome у листопаді 2022-го. Якщо код досі задає висоту з window.innerHeight, він несе обхід проблеми, якої вже немає.

Де це вироджується

HTML і CSS рідко ламаються гучно. Сторінка з десятком проблем зі списку вище все одно рендериться, все одно проходить рев’ю на ноутбуці дизайнера й виглядає завершеною. Ось форми, яких набуває цей занепад.

• Div з обробником кліку замість кнопки — невидимий для клавіатури й для будь-якої допоміжної технології.
• outline: none на фокусі без заміни робить навігацію клавіатурою неможливою для відстеження.
• Заголовки, обрані за розміром, руйнують структуру документа, за якою люди орієнтуються.
• Гонка !important і її близнючка, гонка z-index, — кожна сторона може відповісти лише більшою версією того самого ходу.
• Селектори, що тягнуться через межі компонентів, — жодне правило не можна безпечно видалити.
• Магічні числа — margin-top: 37px — кодують один розмір екрана й ламаються на наступному.
• Зображення без розмірів — текст стрибає під пальцем читача, поки сторінка вантажиться.
• Оверлей доступності — один скрипт, що обіцяє полагодити сторінку, — замість виправлення розмітки. У 2025 році Федеральна торгова комісія США змусила accessiBe заплатити $1 млн за твердження, що її віджет робить будь-який сайт сумісним із WCAG.
• Ідеальна автоматична оцінка доступності, яку вважають фінішем, а не першою перевіркою.

Є й чесна межа, і вона важливіша за будь-який рядок таблиці. Усе на цій сторінці змушує браузер робити те, що ви мали на увазі. Ніщо з цього не каже, чи тим, що ви мали на увазі, можна користуватися. Автоматичні перевірки бачать у кращому разі частину: коли Government Digital Service (GDS) уряду Великої Британії у 2017 році зробила тестову сторінку зі 143 навмисними бар’єрами, найкращий із десяти інструментів знайшов 41% із них, усі десять разом — 71%, а 29% не знайшов жоден, — серед них посилання, позначені лише кольором, які проходять кожне правило, що його може перевірити машина.

Відповідь дешева й не має заміни. Відкладіть мишу й попрацюйте зі сторінкою самою лише клавіатурою п’ять хвилин. Увімкніть зчитувач екрана, який уже є у вашій операційній системі, — VoiceOver на Mac чи iPhone, Narrator у Windows, TalkBack на Android — і спробуйте виконати одну задачу, заради якої сторінка існує. Відкрийте її на справжньому телефоні середнього класу з повільним з’єднанням. Десять хвилин цього знаходять те, чого не знайде жоден лінтер, і це єдина перевірка на цій сторінці, яка тестує обіцянку, а не код.

Коли це застосовувати

Пов’язані сторінки

• РозробкаJavaScriptJavaScript — мова програмування, яку виконує кожен браузер: один потік на сторінку, один стек викликів і черга для всього, що мусить чекати. Більшість того, що здається в ній довільним, випливає з цієї моделі або з рішення перших років мови, яке веб уже не може скасувати. Сторінка починається з дванадцяти несподіванок — кожна з правилом, що за нею стоїть, і виправленням; далі — цикл подій, де асинхронний код губить час і помилки, числа й посилання, область видимості, модулі й дерево залежностей і п’ять задокументованих кейсів.
• РозробкаReactReact — бібліотека JavaScript для побудови інтерфейсів із компонентів, кожен з яких описує, що має бути на екрані за поточного стану. Далі React сам з’ясовує, як змінити сторінку, щоб вона цьому відповідала, і майже всі складнощі з ним походять із порушення цієї моделі: нечиста робота під час рендеру, стан там, де він не може бути джерелом правди, або ефект, що робить чужу роботу. Сторінка починається з усіх вбудованих хуків на одному екрані й чотирьох причин, з яких компонент рендериться; далі — рендер і коміт, перерендери, стан як знімок, ефекти, серверні компоненти й п’ять задокументованих кейсів.
• РозробкаPWAПрогресивний вебзастосунок, або PWA, — це сайт із service worker і вебманіфестом, який можна встановити, який працює офлайн і поводиться як застосунок. SDK для PWA не існує: що може встановлений вебзастосунок, залежить від браузера й платформи, і саме розрив між Chrome на Android і Safari на iPhone визначає більшість продуктових рішень. Сторінка починається з шістнадцяти можливостей і того, де кожна працює в жовтні 2026 року; далі — service worker і оновлення, яке не приходить, стратегії кешування й сховище, яке можуть очистити, встановлення на чотирьох платформах, що дозволяє Apple і як це змінювалося, питання магазинів застосунків, п’ять задокументованих кейсів і те, де все це вироджується.