Вивчаючи принципи базового CSS, вчать писати модульний, багаторазовий та описовий стилі, щоб забезпечити зручність обслуговування. Але коли розробники починають працювати з програмами реального світу, часто здається неможливим додати функції інтерфейсу без витоку стилів у непередбачувані області. Ця проблема часто переростає в самореалізований цикл; стилі, які теоретично обмежені одним елементом або класом, починають з’являтися там, де їм не місце. Це змушує розробника створювати ще більш конкретні селектори для перевизначення витікаючих стилів, які потім випадково перевизначають глобальні стилі тощо. Жорсткі правила імен класів, такі як BEM, є одним з теоретичних рішень цієї проблеми. Методологія BEM (Block, Element, Modifier) — це систематичний спосіб іменування класів CSS для забезпечення повторного використання та структури файлів CSS. Подібні угоди про найменування можуть зменшити когнітивне навантаження за рахунок використання доменної мови для опису елементів та їхнього стану, а якщо вони правильно реалізовані, можуть полегшити підтримку стилів для великих програм. Однак у реальному світі це не завжди так виходить. Пріоритети можуть змінюватися, і зі зміною реалізація стає непослідовною. Невеликі зміни в структурі HTML можуть вимагати багатьох переглядів імен класів CSS. У високоінтерактивних інтерфейсних програмах назви класів, що відповідають шаблону BEM, можуть стати довгими та громіздкими (наприклад, app-user-overview__status--is-authenticating), а неповне дотримання правил іменування порушує структуру системи, тим самим зводячи нанівець її переваги. Зважаючи на ці проблеми, не дивно, що розробники звернулися до фреймворків, серед яких Tailwind є найпопулярнішим фреймворком CSS. Замість того, щоб намагатися боротися з тим, що здається непереможною війною між стилями, простіше відмовитися від CSS Cascade і використовувати інструменти, які гарантують повну ізоляцію. Розробники більше покладаються на утиліти Як ми знаємо, що деякі розробники прагнуть уникати каскадних стилів? Це розвиток «сучасних» зовнішніх інструментів, таких як фреймворки CSS-in-JS, розроблених спеціально для цієї мети. Робота з ізольованими стилями, які тісно пов’язані з окремими компонентами, може здатися ковтком свіжого повітря. Це позбавляє від необхідності називати речі — досі одне з найбільш ненависних і трудомістких інтерфейсних завдань — і дозволяє розробникам бути продуктивними без повного розуміння чи використання переваг успадкування CSS. Але відмова від CSS Cascade має свої проблеми. Наприклад, створення стилів у JavaScript вимагає серйозних конфігурацій збірки та часто призводить до незграбного змішування стилів із розміткою компонентів або HTML. Замість ретельно продуманих правил іменування ми дозволяємо створювати інструменти для автоматичного створення селекторів та ідентифікаторів для нас (наприклад, .jsx-3130221066), вимагаючи від розробників не відставати від ще однієї псевдомови. (Ніби когнітивного навантаження на розуміння того, що роблять useEffects вашого компонента, ще недостатньо!) Подальше абстрагування роботи з присвоєння імен класам інструментам означає, що базове налагодження часто обмежується конкретними версіями програми, скомпільованими для розробки, а не використовує власні функції браузера, які підтримують налагодження в реальному часі, наприклад Інструменти розробника. Це майже так, ніби нам потрібно розробити інструменти для налагодження інструментів, які ми використовуємо, щоб абстрагувати те, що вже надає Інтернет — і все це заради того, щоб уникнути «болю» написання стандартного CSS. На щастя, сучасні функції CSS не тільки роблять написання стандартного CSS більш гнучким, але й дають таким розробникам, як ми, набагато більше можливостей керувати каскадом і змусити його працювати на нас. Каскадні шари CSS є чудовим прикладом, але є ще одна функція, якій напрочуд не приділяється уваги, хоча це змінилося тепер, коли нещодавно стала сумісною з Baseline. CSS @scope At-Rule Я вважаю правило CSS @scope at-rule потенційним ліком від тривоги, спричиненої витоком стилів, яке ми розглянули, яке не змушує нас скомпрометувати рідні веб-переваги для абстракцій та додаткових інструментів для створення. «Правило @scope CSS at дозволяє вибирати елементи в певних піддеревах DOM, точно націлюючи елементи без написання надто специфічних селекторів, які важко перевизначити, і без надто тісного зв’язку ваших селекторів із структурою DOM».— MDN
Іншими словами, ми можемо працювати з ізольованими стилями в конкретних випадках, не жертвуючи успадкуванням, каскадуванням або навіть базовим поділом завданьце був давній керівний принцип розробки інтерфейсу. Крім того, він має чудове покриття браузера. Насправді Firefox 146 додав підтримку @scope в грудні, зробивши його вперше сумісним з Baseline. Ось просте порівняння між кнопкою, яка використовує шаблон BEM, і правилом @scope:
<стиль> .button .button__text { /* стилі тексту кнопки */ } .button .button__icon { /* стилі значка кнопки */ } .button--primary { основні стилі кнопок */ }
<стиль> @scope (.primary-button) { span:first-child { /* стилі тексту кнопки */ } span:last-child { /* стилі значка кнопки */ } }
Правило @scope забезпечує точність з меншою складністю. Розробнику більше не потрібно створювати межі за допомогою назв класів, що, у свою чергу, дозволяє їм писати селектори на основі нативних елементів HTML, тим самим усуваючи потребу в шаблонах імен класів CSS. Просто усунувши потребу в управлінні іменами класів, @scope може зменшити страх, пов’язаний із CSS у великих проектах. Основне використання Щоб розпочати роботу, додайте правило @scope до свого CSS і вставте кореневий селектор, до якого будуть прив’язані стилі: @scope (<селектор>) { /* Стилі в межах <селектора> */ }
Тож, наприклад, якщо ми маємо застосувати стилі до елемента
@scope (навігація) { a { /* Стилі посилань у межах навігації */ }
a:active { /* Активні стилі посилань */ }
a:active::before { /* Активне посилання з псевдоелементом для додаткового стилю */ }
@media (max-width: 768px) { a { /* Адаптивні коригування */ } } }
Це сама по собі не є новаторською функцією. Однак до області можна додати другий аргумент, щоб створити нижню межу, фактично визначаючи початкову та кінцеву точки області.
/* Будь-який елемент всередині ul не матиме застосованих стилів */ @scope (nav) to (ul) { a { розмір шрифту: 14px; } }
Ця практика називається кольцевим оглядом, і існує кілька підходів, які можна використати, включаючи серію подібних, дуже специфічних селекторів, тісно пов’язаних зі структурою DOM, псевдоселектор :not або призначення конкретних імен класів елементам у
Висновок CSS-фреймворки, які є основними утилітами, такі як Tailwind, добре працюють для створення прототипів і невеликих проектів. Однак їхні переваги швидко зменшуються, якщо використовувати їх у великих проектах, в яких бере участь більше ніж пара розробників. За останні кілька років інтерфейсна розробка стає все більш складною, і CSS не є винятком. Хоча правило @scope не є панацеєю від усього, воно може зменшити потребу у складних інструментах. Якщо використовувати @scope замість або поряд зі стратегічним іменуванням класів, це може полегшити та зробити цікавішим написання підтримуваного CSS. Подальше читання
CSS @scope (MDN) «CSS @scope», Хуан Дієго Родрігес (CSS-Tricks) Примітки до випуску Firefox 146 (Firefox) Підтримка браузера (CanIUse) Популярні фреймворки CSS (Стан CSS 2024) «C» у CSS: Cascade», Томас Іп (CSS-Tricks) Вступ до BEM (отримати BEM)
