Når man lærer principperne for grundlæggende CSS, bliver man undervist i at skrive modulære, genanvendelige og beskrivende stilarter for at sikre vedligeholdelse. Men når udviklere bliver involveret i applikationer fra den virkelige verden, føles det ofte umuligt at tilføje UI-funktioner, uden at stilarter lækker ind i utilsigtede områder. Dette problem snegler ofte til en selvopfyldende løkke; stilarter, der teoretisk er scopet til ét element eller klasse, begynder at dukke op, hvor de ikke hører hjemme. Dette tvinger udvikleren til at oprette endnu mere specifikke vælgere for at tilsidesætte de lækkede stilarter, som så ved et uheld tilsidesætter globale stilarter, og så videre. Rigide klassenavnekonventioner, såsom BEM, er en teoretisk løsning på dette problem. BEM-metoden (Block, Element, Modifier) er en systematisk måde at navngive CSS-klasser for at sikre genanvendelighed og struktur i CSS-filer. Navnekonventioner som denne kan reducere kognitiv belastning ved at udnytte domænesprog til at beskrive elementer og deres tilstand, og hvis de implementeres korrekt, kan de gøre stile til store applikationer nemmere at vedligeholde. I den virkelige verden fungerer det dog ikke altid sådan. Prioriteter kan ændre sig, og med ændringer bliver implementeringen inkonsekvent. Små ændringer i HTML-strukturen kan kræve mange revisioner af CSS-klassenavne. Med meget interaktive front-end-applikationer kan klassenavne, der følger BEM-mønsteret, blive lange og uhåndterlige (f.eks. app-bruger-overblik__status--godkender), og manglende overholdelse af navnereglerne bryder systemets struktur og negererer dermed fordelene. I betragtning af disse udfordringer er det ikke underligt, at udviklere har vendt sig til frameworks, hvor Tailwind er det mest populære CSS-framework. I stedet for at forsøge at kæmpe, hvad der ser ud til at være en uvindelig specificitetskrig mellem stilarter, er det lettere at give op på CSS Cascade og bruge værktøjer, der garanterer fuldstændig isolation. Udviklere læner sig mere efter hjælpeprogrammer Hvordan ved vi, at nogle udviklere er ivrige efter at undgå kaskadestile? Det er fremkomsten af "moderne" frontend-værktøjer - som CSS-in-JS-frameworks - designet specifikt til det formål. At arbejde med isolerede stilarter, der er nøje tilpasset specifikke komponenter, kan virke som et frisk pust. Det fjerner behovet for at navngive ting - stadig en af de mest hadede og tidskrævende frontend-opgaver - og giver udviklere mulighed for at være produktive uden fuldt ud at forstå eller udnytte fordelene ved CSS-arv. Men at droppe CSS Cascade kommer med sine egne problemer. For eksempel kræver det tunge build-konfigurationer at komponere typografier i JavaScript og fører ofte til stilarter, der blander sig akavet med komponentmarkering eller HTML. I stedet for nøje overvejede navnekonventioner tillader vi byggeværktøjer til automatisk at generere vælgere og identifikatorer for os (f.eks. .jsx-3130221066), hvilket kræver, at udviklere holder trit med endnu et pseudosprog i sig selv. (Som om den kognitive belastning af at forstå, hvad al din komponents brugseffekter gør, ikke allerede var nok!) Yderligere abstrahering af opgaven med at navngive klasser til værktøj betyder, at grundlæggende fejlfinding ofte er begrænset til specifikke applikationsversioner, der er kompileret til udvikling, snarere end at udnytte native browserfunktioner, der understøtter live debugging, såsom udviklerværktøjer. Det er næsten som om, vi skal udvikle værktøjer til at fejlsøge de værktøjer, vi bruger til at abstrahere, hvad nettet allerede tilbyder - alt sammen for at løbe væk fra "smerten" ved at skrive standard CSS. Heldigvis gør moderne CSS-funktioner ikke kun skrivning af standard CSS mere fleksibel, men giver også udviklere som os meget mere magt til at styre kaskaden og få den til at fungere for os. CSS Cascade Layers er et godt eksempel, men der er en anden funktion, der får en overraskende mangel på opmærksomhed - selvom det ændrer sig nu, hvor det for nylig er blevet Baseline-kompatibelt. CSS @scope At-Rule Jeg anser CSS @scope at-rule for at være en potentiel kur mod den form for stillækage-induceret angst, vi har dækket, en som ikke tvinger os til at kompromittere native web-fordele for abstraktioner og ekstra byggeværktøjer. "@scope CSS at-rule giver dig mulighed for at vælge elementer i specifikke DOM-undertræer, målrette elementer præcist uden at skrive overdrevent specifikke vælgere, som er svære at tilsidesætte, og uden at koble dine vælgere for tæt til DOM-strukturen." — MDN
Med andre ord kan vi arbejde med isolerede stilarter i specifikke tilfælde uden at ofre arv, cascading eller endda den grundlæggende adskillelse af bekymringerdet har været et langvarigt ledende princip for frontend-udvikling. Derudover har den fremragende browserdækning. Faktisk tilføjede Firefox 146 understøttelse af @scope i december, hvilket gjorde det Baseline-kompatibelt for første gang. Her er en simpel sammenligning mellem en knap, der bruger BEM-mønsteret versus @scope-reglen:
@scope-reglen giver mulighed for præcision med mindre kompleksitet. Udvikleren behøver ikke længere at oprette grænser ved hjælp af klassenavne, hvilket igen giver dem mulighed for at skrive vælgere baseret på native HTML-elementer, og derved eliminere behovet for præskriptive CSS-klassenavnemønstre. Ved blot at fjerne behovet for håndtering af klassenavne kan @scope lindre frygten forbundet med CSS i store projekter.
Grundlæggende brug
For at komme i gang skal du tilføje @scope-reglen til din CSS og indsætte en rodvælger, som stilarter vil blive omfattet af:
@scope (
Så hvis vi for eksempel skulle scope styles til et
@scope (nav) { a { /* Linkstile inden for nav-omfang */ }
a:active { /* Active link styles */ }
a:active::before { /* Aktivt link med pseudo-element for ekstra styling */ }
@media (maks. bredde: 768px) { a { /* Responsive justeringer */ } } }
Dette er i sig selv ikke en banebrydende funktion. Et andet argument kan dog tilføjes til omfanget for at skabe en nedre grænse, der effektivt definerer omfangets start- og slutpunkter.
/* Ethvert element inde i ul vil ikke have stilene anvendt */ @scope (nav) til (ul) { en { skriftstørrelse: 14px; } }
Denne praksis kaldes donut scoping, og der er flere tilgange, man kan bruge, inklusive en række lignende, meget specifikke vælgere, der er tæt koblet til DOM-strukturen, en :not pseudo-vælger eller tildeling af specifikke klassenavne til -elementer i
Konklusion Utility-first CSS frameworks, såsom Tailwind, fungerer godt til prototyping og mindre projekter. Deres fordele aftager dog hurtigt, når de bruges i større projekter, der involverer mere end et par udviklere. Frontend-udvikling er blevet mere og mere overkompliceret i de sidste par år, og CSS er ingen undtagelse. Selvom @scope-reglen ikke er en kur-alle, kan den reducere behovet for kompleks værktøj. Når det bruges i stedet for eller sammen med strategisk klassenavngivning, kan @scope gøre det nemmere og sjovere at skrive vedligeholdelsesvenlig CSS. Yderligere læsning
CSS @scope (MDN) “CSS @scope”, Juan Diego Rodríguez (CSS-Tricks) Firefox 146 Release Notes (Firefox) Browsersupport (CanIUse) Populære CSS-rammer (State of CSS 2024) "C'et" i CSS: Cascade, Thomas Yip (CSS-Tricks) BEM Introduktion (Få BEM)
