Når man lærer prinsippene for grunnleggende CSS, læres man å skrive modulære, gjenbrukbare og beskrivende stiler for å sikre vedlikehold. But when developers become involved with real-world applications, it often feels impossible to add UI features without styles leaking into unintended areas. 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. Naming conventions like this can reduce cognitive load by leveraging domain language to describe elements and their state, and if implemented correctly, can make styles for large applications easier to maintain. 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. It removes the need to name things — still one of the most hated and time-consuming front-end tasks — and allows developers to be productive without fully understanding or leveraging the benefits of CSS inheritance. Men å droppe CSS Cascade kommer med sine egne problemer. For instance, composing styles in JavaScript requires heavy build configurations and often leads to styles awkwardly intermingling with component markup or HTML. Instead of carefully considered naming conventions, we allow build tools to autogenerate selectors and identifiers for us (e.g., .jsx-3130221066), requiring developers to keep up with yet another pseudo-language in and of itself. (Som om den kognitive belastningen med å forstå hva alle komponentens brukseffekter gjør ikke allerede var nok!) Further abstracting the job of naming classes to tooling means that basic debugging is often constrained to specific application versions compiled for development, rather than leveraging native browser features that support live debugging, such as Developer Tools. It’s almost like we need to develop tools to debug the tools we’re using to abstract what the web already provides — all for the sake of running away from the “pain” of writing 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 are a great example, but there’s another feature that gets a surprising lack of attention — although that is changing now that it has recently become Baseline compatible. The CSS @scope At-Rule I consider the CSS @scope at-rule to be a potential cure for the sort of style-leak-induced anxiety we’ve covered, one that does not force us to compromise native web advantages for abstractions and extra build tooling. “The @scope CSS at-rule enables you to select elements in specific DOM subtrees, targeting elements precisely without writing overly-specific selectors that are hard to override, and without coupling your selectors too tightly to the DOM structure.”— MDN
In other words, we can work with isolated styles in specific instances without sacrificing inheritance, cascading, or even the basic separation of concernsdet 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)
