Кога ги учиме принципите на основниот CSS, се учи да пишува модуларни, повеќекратно употребливи и описни стилови за да се обезбеди одржливост. Но, кога програмерите ќе се вклучат во апликации од реалниот свет, често се чувствува невозможно да се додадат функции на интерфејс без стилови да протекуваат во несакани области. Ова прашање честопати се претвора во самоисполнувачка јамка; стиловите кои теоретски се опфатени на еден елемент или класа почнуваат да се појавуваат таму каде што не припаѓаат. Ова го принудува развивачот да создаде уште поспецифични селектори за да ги отфрлат протечените стилови, кои потоа случајно ги отфрлаат глобалните стилови итн. Цврстите конвенции за име на класа, како што е BEM, се едно теоретско решение за ова прашање. Методологијата BEM (Block, Element, Modifier) е систематски начин на именување CSS класи за да се обезбеди повторна употреба и структура во CSS-датотеките. Конвенциите за именување како оваа може да го намалат когнитивното оптоварување со користење на јазикот на доменот за опишување на елементите и нивната состојба, и ако се имплементираат правилно, може да го олесни одржувањето на стиловите за големи апликации. Во реалниот свет, сепак, не секогаш функционира така. Приоритетите можат да се променат, а со промената имплементацијата станува неконзистентна. Мали промени во структурата на HTML може да бараат многу ревизии на името на класата CSS. Со високо интерактивни апликации од предниот дел, имињата на класите кои го следат BEM шаблонот може да станат долги и незгодни (на пр., app-user-overview__status--is-authenticating), а нецелосното почитување на правилата за именување ја нарушува структурата на системот, а со тоа ги негира неговите придобивки. Со оглед на овие предизвици, не е ни чудо што програмерите се свртеа кон рамки, а Tailwind е најпопуларната CSS рамка. Наместо да се обидувате да се борите со она што изгледа како непобедлива војна за специфичност меѓу стиловите, полесно е да се откажете од CSS каскадата и да користите алатки кои гарантираат целосна изолација. Програмерите се потпираат повеќе на комуналните услуги Како знаеме дека некои програмери сакаат да избегнуваат каскадни стилови? Тоа е подемот на „модерната“ предна алатка - како што се рамки CSS-in-JS - дизајнирани специјално за таа цел. Работата со изолирани стилови кои се цврсто опфатени со одредени компоненти може да изгледа како здив на свеж воздух. Ја отстранува потребата да се именуваат работите - сè уште една од најомразените и најодземачките задачи од предниот дел - и им овозможува на програмерите да бидат продуктивни без целосно разбирање или искористување на придобивките од наследувањето на CSS. Но, отфрлањето на CSS каскадата доаѓа со свои проблеми. На пример, компонирањето стилови во JavaScript бара тешки конфигурации за градење и често доведува до незгодно мешање на стилови со означување на компонентите или HTML. Наместо внимателно разгледани конвенции за именување, дозволуваме build алатки за автоматско генерирање на избирачи и идентификатори за нас (на пр., .jsx-3130221066), барајќи од програмерите да бидат во тек со уште еден псевдо-јазик сам по себе. (Како когнитивното оптоварување на разбирањето на она што го прават сите ваши ефекти на употребата на компонентите да не е веќе доволно!) Понатамошното апстрактирање на работата за именување класи во алатки значи дека основното дебагирање често е ограничено на специфични верзии на апликации составени за развој, наместо да се користат карактеристиките на мајчин прелистувач што поддржуваат дебагирање во живо, како што се Алатките за програмери. Речиси како да треба да развиеме алатки за да ги дебагираме алатките што ги користиме за да го апстрахираме она што мрежата веќе го обезбедува - сè за да бегаме од „болката“ на пишувањето стандарден CSS. За среќа, модерните карактеристики на CSS не само што го прават пишувањето стандарден CSS пофлексибилен, туку им даваат на програмерите како нас многу поголема моќ да управуваат со каскадата и да ја направат да работи за нас. CSS Cascade Layers се одличен пример, но има уште една карактеристика што добива изненадувачки недостаток на внимание - иако тоа се менува сега кога неодамна стана компатибилно со основната линија. CSS @scope At-Rule Сметам дека CSS @scope at-rule е потенцијален лек за видот на вознемиреност предизвикана од истекување на стилот што ја опфативме, што не нè принудува да ги компромитираме предностите на мајчин веб за апстракции и дополнителни алатки за градење. „@scope CSS at-rule ви овозможува да изберете елементи во специфични поддрва на DOM, таргетирајќи ги елементите прецизно без да пишувате премногу специфични селектори кои тешко се отфрлаат и без премногу цврсто поврзување на вашите избирачи со структурата DOM.“ - MDN
Со други зборови, можеме да работиме со изолирани стилови во одредени случаи без да го жртвуваме наследството, каскадирањето или дури и основното раздвојување на грижитетоа е долготраен водечки принцип за развој на предниот дел. Плус, има одлична покриеност на прелистувачот. Всушност, Firefox 146 додаде поддршка за @scope во декември, што го прави компатибилен со Baseline за прв пат. Еве едноставна споредба помеѓу копче користејќи ја шемата BEM наспроти правилото @scope:
<стил> .button .button__text { /* копче стилови на текст */ } .button .button__icon { /* копче стилови на икона */ } .button--primary {primary buttons styles */ }
<стил> @scope (.primary-button) { span:first-child { /* копче стилови на текст */ } span:last-child { /* копче стилови на икона */ } }
Правилото @scope овозможува прецизност со помала сложеност. Програмерот повеќе не треба да создава граници користејќи имиња на класи, што, пак, им овозможува да пишуваат селектори врз основа на природни HTML елементи, со што се елиминира потребата за прописни модели на имиња на класи CSS. Со едноставно отстранување на потребата за управување со името на класата, @scope може да го ублажи стравот поврзан со CSS во големите проекти. Основна употреба За да започнете, додајте го правилото @scope во вашиот CSS и вметнете root избирач на кој стилови ќе бидат опфатени: @scope (<селектор>) { /* Стиловите се опфатени во <изборникот> */ }
Така, на пример, ако сакаме да ги опфатиме стиловите на елементот
@scope (nav) { a { /* Стилови на врски во опсегот на навигација */ }
a:active { /* Стилови на активни врски */ }
a:active::before { /* Активна врска со псевдоелемент за дополнителен стил */ }
@media (макс-ширина: 768 пиксели) { a { /* Респонзивни прилагодувања */ } } }
Ова, само по себе, не е револуционерна карактеристика. Сепак, може да се додаде втор аргумент во опсегот за да се создаде долна граница, ефикасно дефинирајќи ги почетните и крајните точки на опсегот.
/* Секој елемент во ul нема да ги примени стиловите */ @scope (nav) до (ul) { а { големина на фонтот: 14 px; } }
Оваа практика се нарекува одредување на опсегот на крофни, и постојат неколку пристапи кои може да се користат, вклучувајќи серија слични, многу специфични селектори споени цврсто со структурата DOM, :не псевдо-селектор или доделување специфични имиња на класи на елементите во
Заклучок Рамките за CSS кои се први на Utility, како што е Tailwind, добро функционираат за прототипови и помали проекти. Меѓутоа, нивните придобивки брзо се намалуваат кога се користат во поголеми проекти кои вклучуваат повеќе од неколку програмери. Развојот на предниот дел станува сè покомплициран во последните неколку години, а CSS не е исклучок. Иако правилото @scope не е лек, тоа може да ја намали потребата за сложена алатка. Кога се користи наместо или заедно со стратешкото именување на класите, @scope може да го олесни и позабавно пишувањето CSS што може да се одржува. Понатамошно читање
CSS @scope (MDN) „CSS @scope“, Хуан Диего Родригез (CSS-Tricks) Белешки за издавање на Firefox 146 (Firefox) Поддршка за прелистувач (CanIUse) Популарни CSS Frameworks (состојба на CSS 2024) „Ц“ во CSS: Каскада“, Томас Јип (CSS-трикови) BEM Вовед (Земи BEM)
