När man lär sig principerna för grundläggande CSS, lär man sig att skriva modulära, återanvändbara och beskrivande stilar för att säkerställa underhållbarhet. Men när utvecklare blir involverade i verkliga applikationer känns det ofta omöjligt att lägga till UI-funktioner utan att stilar läcker in i oavsiktliga områden. Denna fråga snöar ofta till en självuppfyllande loop; stilar som är teoretiskt inriktade på ett element eller en klass börjar dyka upp där de inte hör hemma. Detta tvingar utvecklaren att skapa ännu mer specifika väljare för att åsidosätta de läckta stilarna, som sedan av misstag åsidosätter globala stilar, och så vidare. Stela klassnamnkonventioner, såsom BEM, är en teoretisk lösning på detta problem. BEM-metoden (Block, Element, Modifier) är ett systematiskt sätt att namnge CSS-klasser för att säkerställa återanvändbarhet och struktur i CSS-filer. Namnkonventioner som denna kan minska kognitiv belastning genom att utnyttja domänspråket för att beskriva element och deras tillstånd, och om de implementeras korrekt kan det göra stilar för stora applikationer lättare att underhålla. I den verkliga världen fungerar det dock inte alltid så. Prioriteringar kan förändras, och med förändringar blir implementeringen inkonsekvent. Små ändringar i HTML-strukturen kan kräva många CSS-klassnamnrevisioner. Med mycket interaktiva front-end-applikationer kan klassnamn som följer BEM-mönstret bli långa och svårhanterliga (t.ex. app-user-overview__status--är-autentifierar), och att inte helt följa namnreglerna bryter mot systemets struktur, vilket förnekar dess fördelar. Med tanke på dessa utmaningar är det inte konstigt att utvecklare har vänt sig till ramverk, Tailwind är det mest populära CSS-ramverket. Istället för att försöka bekämpa vad som verkar vara ett ovinnligt specificitetskrig mellan stilar, är det lättare att ge upp CSS Cascade och använda verktyg som garanterar fullständig isolering. Utvecklare lutar mer åt verktyg Hur vet vi att vissa utvecklare är angelägna om att undvika kaskadstilar? Det är uppkomsten av "moderna" front-end-verktyg – som CSS-in-JS-ramverk – utformade specifikt för det ändamålet. Att arbeta med isolerade stilar som är tätt anpassade till specifika komponenter kan verka som en frisk fläkt. Det tar bort behovet av att namnge saker – fortfarande en av de mest hatade och tidskrävande front-end-uppgifterna – och tillåter utvecklare att vara produktiva utan att helt förstå eller utnyttja fördelarna med CSS-arv. Men att avstå från CSS Cascade kommer med sina egna problem. Till exempel, att komponera stilar i JavaScript kräver tunga byggkonfigurationer och leder ofta till att stilar besvärligt blandas med komponentmarkering eller HTML. Istället för noggrant övervägda namnkonventioner tillåter vi byggverktyg för att autogenerera väljare och identifierare åt oss (t.ex. .jsx-3130221066), vilket kräver att utvecklare hänger med i ännu ett pseudospråk i sig. (Som om den kognitiva belastningen av att förstå vad all din komponents användningseffekter gör inte redan var tillräckligt!) Att ytterligare abstrahera jobbet med att namnge klasser till verktyg innebär att grundläggande felsökning ofta är begränsad till specifika applikationsversioner som kompileras för utveckling, snarare än att utnyttja inbyggda webbläsarfunktioner som stöder live-felsökning, såsom utvecklarverktyg. Det är nästan som att vi behöver utveckla verktyg för att felsöka de verktyg vi använder för att abstrahera det som webben redan tillhandahåller - allt för att fly från "smärtan" med att skriva standard CSS. Lyckligtvis gör moderna CSS-funktioner inte bara att skriva standard-CSS mer flexibelt utan ger också utvecklare som oss mycket mer kraft att hantera kaskaden och få den att fungera för oss. CSS Cascade Layers är ett bra exempel, men det finns en annan funktion som får en överraskande brist på uppmärksamhet – även om det håller på att förändras nu när det nyligen har blivit Baseline-kompatibelt. CSS @scope At-Rule Jag anser att CSS @scope at-rule är ett potentiellt botemedel mot den typ av stilläckage-inducerad ångest vi har täckt, en som inte tvingar oss att kompromissa med inbyggda webbfördelar för abstraktioner och extra byggverktyg. "@scope CSS at-rule gör att du kan välja element i specifika DOM-underträd, rikta in element exakt utan att skriva alltför specifika väljare som är svåra att åsidosätta, och utan att koppla dina väljare för hårt till DOM-strukturen." — MDN
Med andra ord kan vi arbeta med isolerade stilar i specifika tillfällen utan att offra arv, överlappande eller ens den grundläggande separationen av bekymmerdet har varit en långvarig vägledande princip för front-end-utveckling. Dessutom har den utmärkt webbläsartäckning. Faktum är att Firefox 146 lade till stöd för @scope i december, vilket gjorde det Baseline-kompatibelt för första gången. Här är en enkel jämförelse mellan en knapp som använder BEM-mönstret kontra @scope-regeln:
@scope-regeln tillåter precision med mindre komplexitet. Utvecklaren behöver inte längre skapa gränser med klassnamn, vilket i sin tur låter dem skriva väljare baserade på inbyggda HTML-element, vilket eliminerar behovet av föreskrivande CSS-klassnamnsmönster. Genom att helt enkelt ta bort behovet av klassnamnshantering kan @scope lindra rädslan förknippad med CSS i stora projekt.
Grundläggande användning
För att komma igång, lägg till @scope-regeln i din CSS och infoga en rotväljare som stilar kommer att omfattas av:
@scope (
Så, till exempel, om vi skulle omfånga stilar till ett
@scope (nav) { a { /* Länkstilar inom nav-omfång */ }
a:active { /* Aktiva länkstilar */ }
a:active::before { /* Aktiv länk med pseudo-element för extra styling */ }
@media (maxbredd: 768px) { a { /* Responsiva justeringar */ } } }
Detta i sig är inte en banbrytande funktion. Ett andra argument kan dock läggas till omfånget för att skapa en nedre gräns, som effektivt definierar omfångets start- och slutpunkter.
/* Alla element inuti ul kommer inte att ha stilarna tillämpade */ @scope (nav) till (ul) { en { teckensnittsstorlek: 14px; } }
Denna praxis kallas donut scoping, och det finns flera tillvägagångssätt man kan använda, inklusive en serie liknande, mycket specifika väljare som är tätt kopplade till DOM-strukturen, en :not pseudo-väljare eller att tilldela specifika klassnamn till -element inom
Slutsats Utility-first CSS-ramverk, som Tailwind, fungerar bra för prototyper och mindre projekt. Deras fördelar minskar dock snabbt när de används i större projekt som involverar fler än ett par utvecklare. Front-end-utveckling har blivit allt mer överkomplicerad under de senaste åren, och CSS är inget undantag. Även om @scope-regeln inte är ett botemedel, kan den minska behovet av komplexa verktyg. När det används i stället för, eller tillsammans med strategisk klassnamn, kan @scope göra det enklare och roligare att skriva underhållbar CSS. Ytterligare läsning
CSS @scope (MDN) “CSS @scope”, Juan Diego Rodríguez (CSS-Tricks) Firefox 146 Release Notes (Firefox) Webbläsarstöd (CanIUse) Populära CSS-ramverk (State of CSS 2024) "C:et" i CSS: Cascade, Thomas Yip (CSS-Tricks) BEM Introduktion (Hämta BEM)
