Når man lærer prinsippene for grunnleggende CSS, læres man å skrive modulære, gjenbrukbare og beskrivende stiler for å sikre vedlikehold. Men når utviklere blir involvert i virkelige applikasjoner, føles det ofte umulig å legge til UI-funksjoner uten at stiler lekker inn i utilsiktede områder. Dette problemet snøballer ofte til en selvoppfyllende loop; stiler som teoretisk sett er tilpasset ett element eller en klasse begynner å dukke opp der de ikke hører hjemme. Dette tvinger utvikleren til å lage enda mer spesifikke velgere for å overstyre de lekkede stilene, som deretter ved et uhell overstyrer globale stiler, og så videre. Rigide klassenavnkonvensjoner, som BEM, er en teoretisk løsning på dette problemet. BEM-metoden (Block, Element, Modifier) er en systematisk måte å navngi CSS-klasser for å sikre gjenbrukbarhet og struktur i CSS-filer. Navnekonvensjoner som dette kan redusere kognitiv belastning ved å utnytte domenespråket til å beskrive elementer og deres tilstand, og hvis de implementeres riktig, kan det gjøre stiler for store applikasjoner enklere å vedlikeholde. I den virkelige verden fungerer det imidlertid ikke alltid slik. Prioriteringer kan endres, og med endring blir implementeringen inkonsekvent. Små endringer i HTML-strukturen kan kreve mange revisjoner av CSS-klassenavn. Med svært interaktive front-end-applikasjoner kan klassenavn som følger BEM-mønsteret bli lange og uhåndterlige (f.eks. app-brukeroversikt__status--godkjennes), og det å ikke overholde navneglene bryter systemets struktur, og negerer dermed fordelene. Gitt disse utfordringene er det ikke rart at utviklere har vendt seg til rammeverk, Tailwind er det mest populære CSS-rammeverket. I stedet for å prøve å kjempe mot det som virker som en uvinnelig spesifisitetskrig mellom stiler, er det lettere å gi opp CSS Cascade og bruke verktøy som garanterer fullstendig isolasjon. Utviklere lener seg mer om verktøy Hvordan vet vi at noen utviklere er opptatt av å unngå kaskadestiler? Det er fremveksten av "moderne" front-end-verktøy – som CSS-in-JS-rammeverk – designet spesielt for det formålet. Å jobbe med isolerte stiler som er tett tilpasset spesifikke komponenter kan virke som et friskt pust. Det fjerner behovet for å navngi ting – fortsatt en av de mest hatede og tidkrevende front-end-oppgavene – og lar utviklere være produktive uten å fullt ut forstå eller utnytte fordelene med CSS-arv. Men å droppe CSS Cascade kommer med sine egne problemer. For eksempel krever det å komponere stiler i JavaScript tunge byggekonfigurasjoner og fører ofte til stiler som vanskelig blandes med komponentmarkering eller HTML. I stedet for nøye overveide navnekonvensjoner, tillater vi byggeverktøy for å autogenerere velgere og identifikatorer for oss (f.eks. .jsx-3130221066), noe som krever at utviklere holder tritt med enda et pseudospråk i seg selv. (Som om den kognitive belastningen med å forstå hva alle komponentens brukseffekter gjør ikke allerede var nok!) Ytterligere abstrahering av jobben med å navngi klasser til verktøy betyr at grunnleggende feilsøking ofte er begrenset til spesifikke applikasjonsversjoner som er kompilert for utvikling, i stedet for å utnytte native nettleserfunksjoner som støtter live debugging, for eksempel utviklerverktøy. Det er nesten som om vi trenger å utvikle verktøy for å feilsøke verktøyene vi bruker for å abstrahere det nettet allerede tilbyr – alt for å løpe vekk fra «smerten» ved å skrive standard CSS. Heldigvis gjør moderne CSS-funksjoner ikke bare skriving av standard CSS mer fleksibel, men gir også utviklere som oss mye mer kraft til å administrere kaskaden og få den til å fungere for oss. CSS Cascade Layers er et godt eksempel, men det er en annen funksjon som får en overraskende mangel på oppmerksomhet - selv om det endrer seg nå som det nylig har blitt Baseline-kompatibelt. CSS @scope At-Rule Jeg anser CSS @scope at-rule for å være en potensiell kur for den typen stillekkasje-indusert angst vi har dekket, en som ikke tvinger oss til å kompromittere native web-fordeler for abstraksjoner og ekstra byggeverktøy. "@scope CSS at-rule lar deg velge elementer i spesifikke DOM-undertrær, målrette elementer nøyaktig uten å skrive altfor spesifikke velgere som er vanskelige å overstyre, og uten å koble velgerne dine for tett til DOM-strukturen." — MDN
Med andre ord kan vi jobbe med isolerte stiler i spesifikke tilfeller uten å ofre arv, overlapping eller til og med den grunnleggende separasjonen av bekymringerdet har vært et langvarig ledende prinsipp for frontend-utvikling. I tillegg har den utmerket nettleserdekning. Faktisk la Firefox 146 til støtte for @scope i desember, noe som gjorde den Baseline-kompatibel for første gang. Her er en enkel sammenligning mellom en knapp som bruker BEM-mønsteret versus @scope-regelen:
@scope-regelen tillater presisjon med mindre kompleksitet. Utvikleren trenger ikke lenger å lage grenser ved å bruke klassenavn, som igjen lar dem skrive velgere basert på native HTML-elementer, og dermed eliminere behovet for preskriptive CSS-klassenavnmønstre. Ved ganske enkelt å fjerne behovet for administrasjon av klassenavn, kan @scope lindre frykten knyttet til CSS i store prosjekter.
Grunnleggende bruk
For å komme i gang, legg til @scope-regelen i CSS-en din og sett inn en rotvelger som stiler skal omfattes av:
@scope (
Så, for eksempel, hvis vi skulle bruke stiler til et
@scope (nav) { a { /* Koblingsstiler innenfor nav-omfang */ }
a:active { /* Aktive lenkestiler */ }
a:active::before { /* Aktiv lenke med pseudo-element for ekstra styling */ }
@media (maks-bredde: 768px) { a { /* Responsive justeringer */ } } }
Dette i seg selv er ikke en banebrytende funksjon. Imidlertid kan et andre argument legges til omfanget for å lage en nedre grense, som effektivt definerer omfangets start- og sluttpunkter.
/* Ethvert element i ul vil ikke ha stilene brukt */ @scope (nav) til (ul) { en { skriftstørrelse: 14px; } }
Denne praksisen kalles donut scoping, og det er flere tilnærminger man kan bruke, inkludert en serie med lignende, svært spesifikke velgere koblet tett til DOM-strukturen, en :not pseudo-selektor, eller tilordne spesifikke klassenavn til -elementer i
Konklusjon Utility-første CSS-rammeverk, som Tailwind, fungerer godt for prototyping og mindre prosjekter. Fordelene deres reduseres imidlertid raskt når de brukes i større prosjekter som involverer mer enn et par utviklere. Frontend-utvikling har blitt stadig mer overkomplisert de siste årene, og CSS er intet unntak. Selv om @scope-regelen ikke er en kur-alt, kan den redusere behovet for kompleks verktøy. Når det brukes i stedet for, eller sammen med strategisk klassenavn, kan @scope gjøre det enklere og morsommere å skrive vedlikeholdbar CSS. Videre lesing
CSS @scope (MDN) “CSS @scope”, Juan Diego Rodríguez (CSS-Tricks) Firefox 146 versjonsmerknader (Firefox) Nettleserstøtte (CanIUse) Populære CSS-rammer (State of CSS 2024) "C" i CSS: Cascade, Thomas Yip (CSS-Tricks) BEM-introduksjon (Få BEM)
