Kur mësoni parimet e CSS bazë, dikush mësohet të shkruajë stile modulare, të ripërdorshme dhe përshkruese për të siguruar mirëmbajtjen. Por kur zhvilluesit përfshihen me aplikacione të botës reale, shpesh ndihet e pamundur të shtohen veçoritë e UI pa rrjedhjen e stileve në zona të padëshiruara. Kjo çështje shpesh shndërrohet në një lak vetë-përmbushëse; stilet që janë teorikisht të shtrira në një element ose klasë fillojnë të shfaqen aty ku nuk i përkasin. Kjo e detyron zhvilluesin të krijojë përzgjedhës edhe më specifikë për të anashkaluar stilet e rrjedhura, të cilat më pas anashkalojnë aksidentalisht stilet globale, e kështu me radhë. Konventat e ngurta të emrave të klasës, të tilla si BEM, janë një zgjidhje teorike për këtë çështje. Metodologjia BEM (Block, Element, Modifier) është një mënyrë sistematike e emërtimit të klasave CSS për të siguruar ripërdorimin dhe strukturën brenda skedarëve CSS. Konventat e emërtimit si kjo mund të zvogëlojnë ngarkesën njohëse duke përdorur gjuhën e domenit për të përshkruar elementët dhe gjendjen e tyre, dhe nëse zbatohen siç duhet, mund t'i bëjnë stilet për aplikacione të mëdha më të lehta për t'u ruajtur. Në botën reale, megjithatë, jo gjithmonë funksionon kështu. Prioritetet mund të ndryshojnë dhe me ndryshimin, zbatimi bëhet i paqëndrueshëm. Ndryshime të vogla në strukturën HTML mund të kërkojnë shumë rishikime të emrave të klasës CSS. Me aplikacionet e përparme shumë ndërvepruese, emrat e klasave që ndjekin modelin BEM mund të bëhen të gjatë dhe të pafuqishëm (p.sh., app-user-overview__status--is-authenticating) dhe mosrespektimi i plotë i rregullave të emërtimit thyen strukturën e sistemit, duke mohuar përfitimet e tij. Duke pasur parasysh këto sfida, nuk është çudi që zhvilluesit i janë drejtuar kornizave, ku Tailwind është korniza më e njohur CSS. Në vend që të përpiqeni të luftoni atë që duket si një luftë specifike e pafitueshme midis stileve, është më e lehtë të hiqni dorë nga CSS Cascade dhe të përdorni mjete që garantojnë izolim të plotë. Zhvilluesit mbështeten më shumë në shërbimet komunale Si e dimë se disa zhvillues janë të prirur të shmangin stilet e kaskadës? Është ngritja e veglave "moderne" të pjesës së përparme - si kornizat CSS-në-JS - të krijuara posaçërisht për këtë qëllim. Puna me stile të izoluara që janë të lidhura ngushtë me komponentë specifikë mund të duket si një frymëmarrje e ajrit të pastër. Ai heq nevojën për të emërtuar gjërat - ende një nga detyrat më të urryera dhe që kërkon shumë kohë - dhe u lejon zhvilluesve të jenë produktivë pa i kuptuar ose shfrytëzuar plotësisht përfitimet e trashëgimisë CSS. Por heqja e kaskadës CSS vjen me problemet e veta. Për shembull, kompozimi i stileve në JavaScript kërkon konfigurime të rënda ndërtimi dhe shpesh çon në ndërthurjen e vështirë të stileve me shënjimin e komponentëve ose HTML. Në vend të konventave të emërtimit të konsideruara me kujdes, ne lejojmë veglat e ndërtimit për të gjeneruar automatikisht përzgjedhësit dhe identifikuesit për ne (p.sh., .jsx-3130221066), duke kërkuar që zhvilluesit të vazhdojnë me një tjetër pseudo-gjuhë në vetvete. (Sikur ngarkesa njohëse e të kuptuarit se çfarë bëjnë të gjitha përdorimet e komponentit tuajEffects nuk ishte tashmë e mjaftueshme!) Abstragimi i mëtejshëm i punës së emërtimit të klasave në vegla do të thotë që korrigjimi bazë shpesh kufizohet në versione specifike të aplikacioneve të përpiluara për zhvillim, në vend që të shfrytëzojë veçoritë vendase të shfletuesit që mbështesin korrigjimin e drejtpërdrejtë, të tilla si Veglat e Zhvilluesve. Është pothuajse sikur ne duhet të zhvillojmë mjete për të korrigjuar mjetet që po përdorim për të abstraguar atë që ueb-i tashmë ofron – të gjitha për të ikur nga “dhimbja” e shkrimit të CSS standarde. Për fat të mirë, veçoritë moderne të CSS jo vetëm që e bëjnë shkrimin e CSS standard më fleksibël, por gjithashtu u japin zhvilluesve si ne shumë më shumë fuqi për të menaxhuar kaskadën dhe për ta bërë atë të funksionojë për ne. Shtresat e kaskadës së CSS janë një shembull i shkëlqyeshëm, por ka një veçori tjetër që merr një mungesë befasuese të vëmendjes – megjithëse kjo po ndryshon tani që së fundmi është bërë e përputhshme me bazën. CSS @scope At-Rule Unë e konsideroj CSS @scope at-rule si një kurë të mundshme për llojin e ankthit të shkaktuar nga rrjedhjet e stilit që kemi mbuluar, një që nuk na detyron të komprometojmë avantazhet vendase të uebit për abstraksione dhe vegla shtesë ndërtimi. "@scope CSS at-rule ju mundëson të zgjidhni elementë në nënpemë specifike DOM, duke synuar saktësisht elementë pa shkruar përzgjedhës tepër specifikë që janë të vështirë për t'u anashkaluar dhe pa i bashkuar shumë fort përzgjedhësit tuaj me strukturën DOM." - MDN.
Me fjalë të tjera, ne mund të punojmë me stile të izoluara në raste specifike pa sakrifikuar trashëgiminë, kaskadimin, apo edhe ndarjen bazë të shqetësimeveqë ka qenë një parim udhëzues afatgjatë i zhvillimit të front-end. Plus, ka mbulim të shkëlqyer të shfletuesit. Në fakt, Firefox 146 shtoi mbështetjen për @scope në dhjetor, duke e bërë atë të pajtueshëm për herë të parë në Baseline. Këtu është një krahasim i thjeshtë midis një butoni që përdor modelin BEM kundrejt rregullit @scope:
Rregulli @scope lejon saktësi me më pak kompleksitet. Zhvilluesi nuk ka më nevojë të krijojë kufij duke përdorur emrat e klasave, gjë që, nga ana tjetër, i lejon ata të shkruajnë përzgjedhës të bazuar në elementët vendas të HTML, duke eliminuar kështu nevojën për modele të emrave të klasës CSS. Duke hequr thjesht nevojën për menaxhimin e emrit të klasës, @scope mund të lehtësojë frikën e lidhur me CSS në projekte të mëdha.
Përdorimi bazë
Për të filluar, shtoni rregullin @scope në CSS tuaj dhe futni një përzgjedhës rrënjë në të cilin stilet do të shtrihen:
@scope (
Kështu, për shembull, nëse do t'i shtrinim stilet në një element
@scope (nav) { a { /* Stilet e lidhjes brenda fushës së navigimit */ }
a:active { /* Stilet aktive të lidhjes */ }
a:active::fore { /* Lidhje aktive me pseudo-element për stilim shtesë */ }
@media (gjerësia maksimale: 768 px) { a { /* Rregullime të përgjegjshme */ } } }
Kjo, në vetvete, nuk është një tipar novator. Megjithatë, një argument i dytë mund t'i shtohet fushës së veprimit për të krijuar një kufi më të ulët, duke përcaktuar në mënyrë efektive pikën e fillimit dhe të përfundimit të fushës.
/* Çdo element brenda ul nuk do të ketë stilet e aplikuara */ @scope (nav) në (ul) { nje { madhësia e shkronjave: 14 px; } }
Kjo praktikë quhet shtrirja e donut dhe ka disa qasje që mund të përdoren, duke përfshirë një seri përzgjedhëssh të ngjashëm, shumë specifikë të lidhur ngushtë me strukturën DOM, një pseudo-zgjedhës :jo, ose caktimin e emrave të klasave specifike për elementët brenda
konkluzioni Kornizat CSS të parë të shërbimeve, të tilla si Tailwind, funksionojnë mirë për prototipizim dhe projekte më të vogla. Megjithatë, përfitimet e tyre zvogëlohen shpejt, kur përdoren në projekte më të mëdha që përfshijnë më shumë se disa zhvillues. Zhvillimi i front-end është bërë gjithnjë e më tepër i ndërlikuar në vitet e fundit, dhe CSS nuk bën përjashtim. Ndërsa rregulli @scope nuk është një kurë, ai mund të zvogëlojë nevojën për vegla komplekse. Kur përdoret në vend ose krahas emërtimit strategjik të klasës, @scope mund ta bëjë më të lehtë dhe më argëtues shkrimin e CSS të mirëmbajtur. Lexim i mëtejshëm
CSS @scope (MDN) “CSS @scope”, Juan Diego Rodríguez (CSS-Tricks) Shënimet e publikimit të Firefox 146 (Firefox) Mbështetja e shfletuesit (CanIUse) Kornizat popullore CSS (Gjendja e CSS 2024) "C" në CSS: Cascade", Thomas Yip (CSS-Tricks) Hyrje BEM (Merr BEM)
