HTML та CSS

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

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

За цим стоїть дерево доступності. Розбираючи ваш HTML, браузер поряд із DOM будує другу структуру, у якій кожен вузол має роль, ім’я, стан і набір підтримуваних дій. Зчитувачі екрана, голосове керування, режими читання в браузері та пошукові краулери читають саме це дерево, а не ваш CSS. Семантичні елементи наповнюють його правильно й безкоштовно; несемантичні лишають порожнім і потребують ручного заповнення через атрибути ARIA.

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

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

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

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

Розкладка: flow, flex, grid

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

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

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

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

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

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

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

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

Як це виявляється в реальній поставці

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

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

• Div з обробником кліку замість кнопки — невидимий для клавіатури й для будь-якої допоміжної технології.
• outline: none на фокусі без заміни робить навігацію клавіатурою неможливою для відстеження.
• Заголовки, обрані за розміром, руйнують структуру документа, за якою люди орієнтуються.
• Гонка !important, де кожна сторона може відповісти лише ще одним.
• Селектори, що тягнуться через межі компонентів, — жодне правило не можна безпечно видалити.
• Магічні числа — margin-top: 37px — кодують один розмір екрана й ламаються на наступному.
• Зображення без розмірів — текст стрибає під пальцем читача, поки сторінка вантажиться.

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

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

• РозробкаJavaScriptJavaScript — це мова, яку виконує кожен браузер, і та, яку більшість вчить із синтаксису й ніколи — із семантики. Майже все, що здається в ній довільним, випливає з одного факту: ваш код виконується в одному потоці з одним стеком викликів, а все асинхронне — це черга, що чекає, доки стек спорожніє. На цій сторінці — цикл подій, посилання, замикання, модулі й те, де обробка помилок в асинхронному коді тихо провалюється.
• РозробкаReactReact — це бібліотека для опису того, як має виглядати інтерфейс за поточного стану, з тим, щоб хтось інший з’ясував, як довести до цього DOM. Модель уміщається в рядок — інтерфейс є функцією стану, — і майже всі складнощі з React походять із її порушення: нечистої роботи під час рендеру або стану, що лежить там, де не може бути джерелом правди.
• РозробкаДизайн APIДизайн API — це робота над поверхнею, на якій будують інші. Корисна рамка — одна лінія: над нею контракт, на який спираються споживачі і який ви не змінюєте самотужки; під нею реалізація, яку можна переписати у вівторок. Більшість того, що робить API болісним у житті, — це рішення, яке опинилося не на тому боці цієї лінії.