Пры вывучэнні прынцыпаў базавага CSS вучаць пісаць модульныя, шматразовыя і апісальныя стылі для забеспячэння зручнасці абслугоўвання. Але калі распрацоўшчыкі пачынаюць працаваць з рэальнымі праграмамі, часта здаецца немагчымым дадаць функцыі карыстацкага інтэрфейсу без уцечкі стыляў у непрадбачаныя вобласці. Гэтая праблема часта перарастае ў самарэалізаваны цыкл; стылі, якія тэарэтычна адносяцца да аднаго элемента або класа, пачынаюць з'яўляцца там, дзе ім не месца. Гэта прымушае распрацоўшчыка ствараць яшчэ больш спецыфічныя селектары для перавызначэння прасачыліся стыляў, якія потым выпадкова перавызначаюць глабальныя стылі і г.д. Жорсткія пагадненні аб назвах класаў, такія як БЭМ, з'яўляюцца адным з тэарэтычных рашэнняў гэтай праблемы. Метадалогія 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 Cascade Layers з'яўляюцца выдатным прыкладам, але ёсць яшчэ адна асаблівасць, якой дзіўна не хапае ўвагі - хоць гэта мяняецца цяпер, калі яна нядаўна стала сумяшчальнай з 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 (максімальная шырыня: 768 пікселяў) { a { /* Адаптыўныя карэкціроўкі */ } } }
Сама па сабе гэта не наватарская функцыя. Аднак другі аргумент можа быць дададзены да вобласці, каб стварыць ніжнюю мяжу, эфектыўна вызначаючы пачатковую і канчатковую кропкі вобласці.
/* Любы элемент у ul не будзе мець стыляў */ @scope (nav) да (ul) { a { памер шрыфта: 14 пікселяў; } }
Гэтую практыку называюць ахопам пончыка, і можна выкарыстоўваць некалькі падыходаў, у тым ліку шэраг падобных, вельмі спецыфічных селектараў, цесна звязаных са структурай DOM, псеўдаселектар :not або прысваенне пэўных імёнаў класаў элементам у
Заключэнне Карысныя структуры CSS, такія як Tailwind, добра працуюць для стварэння прататыпаў і невялікіх праектаў. Аднак іх перавагі хутка змяншаюцца пры выкарыстанні ў вялікіх праектах з удзелам больш чым пары распрацоўшчыкаў. За апошнія некалькі гадоў інтэрфейсная распрацоўка становіцца ўсё больш складанай, і CSS не з'яўляецца выключэннем. Нягледзячы на тое, што правіла @scope не панацэя, яно можа паменшыць патрэбу ў складаных інструментах. Пры выкарыстанні замест або разам са стратэгічным найменнем класа @scope можа зрабіць прасцей і цікавей напісанне CSS, які падтрымліваецца. Далейшае чытанне
CSS @scope (MDN) «CSS @scope», Хуан Дыега Радрыгес (CSS-Tricks) Заўвагі да выпуску Firefox 146 (Firefox) Падтрымка браўзера (CanIUse) Папулярныя CSS Frameworks (стан CSS 2024) «С» у CSS: Cascade», Томас Іп (CSS-Tricks) Увядзенне ў BEM (Атрымаць BEM)
