Wanneer jy die beginsels van basiese CSS leer, word mens geleer om modulêre, herbruikbare en beskrywende style te skryf om onderhoubaarheid te verseker. Maar wanneer ontwikkelaars betrokke raak by werklike toepassings, voel dit dikwels onmoontlik om UI-kenmerke by te voeg sonder dat style na onbedoelde gebiede lek. Hierdie kwessie sneeu dikwels in 'n selfvervullende lus; style wat teoreties omvang is na een element of klas begin verskyn waar hulle nie hoort nie. Dit dwing die ontwikkelaar om selfs meer spesifieke keurders te skep om die uitgelekte style te ignoreer, wat dan per ongeluk globale style ignoreer, ensovoorts. Rigiede klasnaamkonvensies, soos BEM, is een teoretiese oplossing vir hierdie kwessie. Die BEM (Blok, Element, Modifier) metodologie is 'n sistematiese manier om CSS-klasse te benoem om herbruikbaarheid en struktuur binne CSS-lêers te verseker. Benoemingskonvensies soos hierdie kan kognitiewe las verminder deur gebruik te maak van domeintaal om elemente en hul toestand te beskryf, en as dit korrek geïmplementeer word, kan dit style vir groot toepassings makliker maak om te onderhou. In die regte wêreld werk dit egter nie altyd so uit nie. Prioriteite kan verander, en met verandering word implementering inkonsekwent. Klein veranderinge aan die HTML-struktuur kan baie CSS-klasnaamhersienings vereis. Met hoogs interaktiewe front-end-toepassings kan klasname wat die BEM-patroon volg, lank en onhandelbaar word (bv. app-gebruiker-oorsig__status--is-verifieer), en die nie ten volle nakoming van die naamreëls breek die stelsel se struktuur en ontken daardeur die voordele daarvan. Gegewe hierdie uitdagings, is dit geen wonder dat ontwikkelaars hulle tot raamwerke gewend het nie, want Tailwind is die gewildste CSS-raamwerk. Eerder as om te probeer veg wat lyk soos 'n onoorwinbare spesifisiteitsoorlog tussen style, is dit makliker om die CSS Cascade op te gee en gereedskap te gebruik wat volledige isolasie waarborg. Ontwikkelaars Leun Meer Op Utilities Hoe weet ons dat sommige ontwikkelaars gretig is om kaskadestyle te vermy? Dit is die opkoms van "moderne" front-end gereedskap - soos CSS-in-JS-raamwerke - wat spesifiek vir daardie doel ontwerp is. Om met geïsoleerde style te werk wat noukeurig na spesifieke komponente gekoppel is, kan soos 'n vars lug lyk. Dit verwyder die behoefte om dinge te noem – steeds een van die mees gehate en tydrowende front-end take – en laat ontwikkelaars toe om produktief te wees sonder om die voordele van CSS-erfenis ten volle te verstaan of te benut. Maar om die CSS Cascade te laat vaar kom met sy eie probleme. Byvoorbeeld, die samestelling van style in JavaScript vereis swaar boukonfigurasies en lei dikwels tot style wat ongemaklik met komponentopmaak of HTML vermeng. In plaas daarvan dat naamkonvensies noukeurig oorweeg word, laat ons bounutsgoed toe om keurders en identifiseerders vir ons outomaties te genereer (bv. .jsx-3130221066), wat vereis dat ontwikkelaars tred hou met nog 'n pseudotaal op sigself. (Asof die kognitiewe las om te verstaan wat al jou komponent se gebruikseffekte doen nie reeds genoeg was nie!) Die verdere abstrahering van die taak om klasse na gereedskap te noem, beteken dat basiese ontfouting dikwels beperk word tot spesifieke toepassingsweergawes wat vir ontwikkeling saamgestel is, eerder as om gebruik te maak van inheemse blaaierkenmerke wat lewendige ontfouting ondersteun, soos ontwikkelaarnutsgoed. Dit is amper asof ons gereedskap moet ontwikkel om die gereedskap wat ons gebruik om te ontfout wat die web reeds bied – alles om weg te hardloop van die “pyn” om standaard CSS te skryf, te ontfout. Gelukkig maak moderne CSS-kenmerke nie net die skryf van standaard CSS meer buigsaam nie, maar gee dit ook ontwikkelaars soos ons baie meer krag om die kaskade te bestuur en dit vir ons te laat werk. CSS Cascade Layers is 'n goeie voorbeeld, maar daar is nog 'n kenmerk wat 'n verrassende gebrek aan aandag kry - hoewel dit besig is om te verander noudat dit onlangs Baseline-versoenbaar geword het. Die CSS @scope At-Rule Ek beskou die CSS @scope at-rule as 'n potensiële genesing vir die soort angs wat deur styllek veroorsaak word, een wat ons nie dwing om inheemse webvoordele vir abstraksies en ekstra bougereedskap in die gedrang te bring nie. "Die @scope CSS at-rule stel jou in staat om elemente in spesifieke DOM-subbome te selekteer, elemente presies te teiken sonder om oorspesifieke keurders te skryf wat moeilik is om te ignoreer, en sonder om jou keurders te styf aan die DOM-struktuur te koppel."— MDN
Met ander woorde, ons kan in spesifieke gevalle met geïsoleerde style werk sonder om erfenis, kaskade of selfs die basiese skeiding van bekommernisse op te offer.dit was 'n langdurige leidende beginsel van front-end ontwikkeling. Boonop het dit uitstekende blaaierdekking. Trouens, Firefox 146 het in Desember ondersteuning vir @scope bygevoeg, wat dit vir die eerste keer Baseline-versoenbaar maak. Hier is 'n eenvoudige vergelyking tussen 'n knoppie wat die BEM-patroon gebruik teenoor die @scope-reël:
Die @scope-reël maak voorsiening vir presisie met minder kompleksiteit. Die ontwikkelaar hoef nie meer grense te skep deur klasname te gebruik nie, wat hulle op sy beurt in staat stel om keurders te skryf gebaseer op inheemse HTML-elemente, en sodoende die behoefte aan voorskriftelike CSS-klasnaampatrone uit te skakel. Deur eenvoudig die behoefte aan klasnaambestuur te verwyder, kan @scope die vrees wat met CSS in groot projekte geassosieer word, verlig.
Basiese gebruik
Om aan die gang te kom, voeg die @scope-reël by jou CSS en voeg 'n wortelkieser in waarin style omvang sal word:
@scope (
So, byvoorbeeld, as ons style na 'n
@scope (nav) { a { /* Skakelstyle binne navigasie-omvang */ }
a:aktiewe { /* Aktiewe skakelstyle */ }
a:active::before { /* Aktiewe skakel met pseudo-element vir ekstra stilering */ }
@media (maksimum breedte: 768px) { a { /* Responsiewe aanpassings */ } } }
Dit op sy eie is nie 'n baanbrekende kenmerk nie. 'n Tweede argument kan egter by die omvang gevoeg word om 'n ondergrens te skep, wat die omvang se begin- en eindpunte effektief definieer.
/* Enige element binne ul sal nie die style toegepas hê nie */ @scope (nav) na (ul) { 'n { lettergrootte: 14px; } }
Hierdie praktyk word doughnut scoping genoem, en daar is verskeie benaderings wat 'n mens kan gebruik, insluitend 'n reeks soortgelyke, hoogs spesifieke keurders wat styf gekoppel is aan die DOM-struktuur, 'n :not pseudo-selektor, of die toekenning van spesifieke klasname aan -elemente binne die
Gevolgtrekking Nut-eerste CSS-raamwerke, soos Tailwind, werk goed vir prototipering en kleiner projekte. Hul voordele verminder egter vinnig wanneer dit gebruik word in groter projekte waarby meer as 'n paar ontwikkelaars betrokke is. Front-end-ontwikkeling het die afgelope paar jaar al hoe meer gekompliseerd geraak, en CSS is geen uitsondering nie. Alhoewel die @scope-reël nie 'n oplossing is nie, kan dit die behoefte aan komplekse gereedskap verminder. Wanneer dit in die plek van, of saam met strategiese klasbenaming gebruik word, kan @scope dit makliker en lekkerder maak om onderhoubare CSS te skryf. Verdere lees
CSS @scope (MDN) “CSS @scope”, Juan Diego Rodríguez (CSS-Tricks) Firefox 146-vrystellingsnotas (Firefox) Blaaierondersteuning (CanIUse) Gewilde CSS-raamwerke (State of CSS 2024) "Die "C" in CSS: Cascade, Thomas Yip (CSS-Tricks) BEM Inleiding (Kry BEM)
