Bij het leren van de principes van basis-CSS wordt geleerd modulaire, herbruikbare en beschrijvende stijlen te schrijven om onderhoudbaarheid te garanderen. Maar wanneer ontwikkelaars betrokken raken bij toepassingen in de echte wereld, voelt het vaak onmogelijk om UI-functies toe te voegen zonder dat stijlen naar onbedoelde gebieden lekken. Deze kwestie zorgt vaak voor een zichzelf vervullende lus; stijlen die theoretisch beperkt zijn tot één element of klasse, verschijnen waar ze niet thuishoren. Dit dwingt de ontwikkelaar om nog specifiekere selectors te maken om de gelekte stijlen te overschrijven, die vervolgens per ongeluk de globale stijlen overschrijven, enzovoort. Stijve conventies voor klassennamen, zoals BEM, zijn een theoretische oplossing voor dit probleem. De BEM-methodologie (Block, Element, Modifier) is een systematische manier om CSS-klassen een naam te geven om herbruikbaarheid en structuur binnen CSS-bestanden te garanderen. Dit soort naamgevingsconventies kunnen de cognitieve belasting verminderen door gebruik te maken van domeintaal om elementen en hun status te beschrijven, en kunnen, indien correct geïmplementeerd, stijlen voor grote applicaties gemakkelijker te onderhouden maken. In de echte wereld werkt het echter niet altijd zo. Prioriteiten kunnen veranderen, en met verandering wordt de implementatie inconsistent. Kleine wijzigingen in de HTML-structuur kunnen veel herzieningen van de CSS-klassenaam vereisen. Met zeer interactieve front-end-applicaties kunnen klassenamen die het BEM-patroon volgen lang en log worden (bijvoorbeeld app-gebruikersoverzicht__status--is-authenticeren), en het niet volledig naleven van de naamgevingsregels verbreekt de structuur van het systeem, waardoor de voordelen ervan teniet worden gedaan. Gezien deze uitdagingen is het geen wonder dat ontwikkelaars zich tot frameworks hebben gewend, waarbij Tailwind het populairste CSS-framework is. In plaats van te proberen een schijnbaar onwinbare specificiteitsoorlog tussen stijlen te voeren, is het gemakkelijker om de CSS Cascade op te geven en tools te gebruiken die volledige isolatie garanderen. Ontwikkelaars leunen meer op hulpprogramma's Hoe weten we dat sommige ontwikkelaars trapsgewijze stijlen graag willen vermijden? Het is de opkomst van ‘moderne’ front-end-tooling – zoals CSS-in-JS-frameworks – die speciaal voor dat doel zijn ontworpen. Het werken met geïsoleerde stijlen die strak zijn afgestemd op specifieke componenten kan een verademing lijken. Het elimineert de noodzaak om dingen een naam te geven (nog steeds een van de meest gehate en tijdrovende front-end-taken) en stelt ontwikkelaars in staat productief te zijn zonder de voordelen van CSS-overerving volledig te begrijpen of te benutten. Maar het dumpen van de CSS Cascade brengt zijn eigen problemen met zich mee. Het samenstellen van stijlen in JavaScript vereist bijvoorbeeld zware bouwconfiguraties en leidt er vaak toe dat stijlen onhandig vermengen met componentmarkeringen of HTML. In plaats van zorgvuldig overwogen naamgevingsconventies staan we bouwtools toe om automatisch selectors en identifiers voor ons te genereren (bijvoorbeeld .jsx-3130221066), waardoor ontwikkelaars op de hoogte moeten blijven van nog een andere pseudo-taal op zichzelf. (Alsof de cognitieve belasting van het begrijpen van wat alle gebruikseffecten van uw component doen, nog niet genoeg was!) Het verder abstraheren van de taak van het benoemen van klassen naar tooling betekent dat basisfoutopsporing vaak beperkt is tot specifieke applicatieversies die zijn gecompileerd voor ontwikkeling, in plaats van gebruik te maken van native browserfuncties die live foutopsporing ondersteunen, zoals Developer Tools. Het is bijna alsof we tools moeten ontwikkelen om de tools die we gebruiken te debuggen om te abstraheren wat het web al biedt – allemaal om te ontsnappen aan de ‘pijn’ van het schrijven van standaard CSS. Gelukkig maken moderne CSS-functies het schrijven van standaard CSS niet alleen flexibeler, maar geven ontwikkelaars zoals wij ook veel meer macht om de cascade te beheren en voor ons te laten werken. CSS-cascadelagen zijn een goed voorbeeld, maar er is nog een functie die verrassend weinig aandacht krijgt, hoewel dat aan het veranderen is nu het onlangs Baseline-compatibel is geworden. De CSS @scope At-regel Ik beschouw de CSS @scope-at-rule als een potentiële remedie voor het soort door stijllekken veroorzaakte angst dat we hebben besproken, een die ons niet dwingt om native webvoordelen in te leveren voor abstracties en extra build-tools. “Met de @scope CSS at-rule kun je elementen in specifieke DOM-substructuren selecteren, waarbij je elementen nauwkeurig kunt targeten zonder al te specifieke selectors te schrijven die moeilijk te overschrijven zijn, en zonder je selectors te strak aan de DOM-structuur te koppelen.”– MDN
Met andere woorden: we kunnen in specifieke gevallen met geïsoleerde stijlen werken zonder dat dit ten koste gaat van overerving, cascadering of zelfs de fundamentele scheiding van belangen.dat is al lang een leidend principe van front-end-ontwikkeling. Bovendien heeft het een uitstekende browserdekking. Firefox 146 heeft in december zelfs ondersteuning voor @scope toegevoegd, waardoor het voor het eerst Baseline-compatibel werd. Hier is een eenvoudige vergelijking tussen een knop die het BEM-patroon gebruikt en de @scope-regel:
De @scope-regel zorgt voor precisie met minder complexiteit. De ontwikkelaar hoeft niet langer grenzen te stellen met behulp van klassenamen, wat hem op zijn beurt in staat stelt selectors te schrijven op basis van native HTML-elementen, waardoor de noodzaak voor prescriptieve CSS-klassenaampatronen wordt geëlimineerd. Door simpelweg de noodzaak voor klassennaambeheer weg te nemen, kan @scope de angst wegnemen die gepaard gaat met CSS in grote projecten.
Basisgebruik
Om aan de slag te gaan, voegt u de @scope-regel toe aan uw CSS en voegt u een rootselector in waarop stijlen worden afgestemd:
@scope (
Als we bijvoorbeeld stijlen zouden toepassen op een
@scope (navigatie) { a { /* Linkstijlen binnen navigatiebereik */ }
a:active { /* Actieve linkstijlen */ }
a:active::before { /* Actieve link met pseudo-element voor extra styling */ }
@media (max. breedte: 768px) { a { /* Responsieve aanpassingen */ } } }
Dit is op zichzelf geen baanbrekend kenmerk. Er kan echter een tweede argument aan de reikwijdte worden toegevoegd om een ondergrens te creëren, waarmee effectief de begin- en eindpunten van de reikwijdte worden gedefinieerd.
/* Op elk element binnen ul worden de stijlen niet toegepast */ @scope (nav) naar (ul) { een { lettergrootte: 14px; } }
Deze praktijk wordt donut scoping genoemd, en er zijn verschillende benaderingen die je zou kunnen gebruiken, waaronder een reeks vergelijkbare, zeer specifieke selectors die nauw zijn gekoppeld aan de DOM-structuur, een :not pseudo-selector, of het toewijzen van specifieke klassenamen aan elementen binnen de
Conclusie Utility-first CSS-frameworks, zoals Tailwind, werken goed voor prototyping en kleinere projecten. De voordelen ervan nemen echter snel af als ze worden gebruikt in grotere projecten waarbij meer dan een paar ontwikkelaars betrokken zijn. Front-end-ontwikkeling is de afgelopen jaren steeds ingewikkelder geworden, en CSS is daarop geen uitzondering. Hoewel de @scope-regel geen wondermiddel is, kan deze de behoefte aan complexe tools verminderen. Wanneer @scope wordt gebruikt in plaats van of naast strategische klassennaamgeving, kan het gemakkelijker en leuker worden om onderhoudbare CSS te schrijven. Verder lezen
CSS @scope (MDN) “CSS @scope”, Juan Diego Rodríguez (CSS-trucs) Release-opmerkingen voor Firefox 146 (Firefox) Browserondersteuning (CanIUse) Populaire CSS-frameworks (State of CSS 2024) “De “C” in CSS: Cascade”, Thomas Yip (CSS-trucs) BEM-introductie (BEM ophalen)
