Quan s'aprèn els principis de CSS bàsic, s'ensenya a escriure estils modulars, reutilitzables i descriptius per garantir el manteniment. Però quan els desenvolupadors s'impliquen amb aplicacions del món real, sovint se sent impossible afegir funcions d'interfície d'usuari sense que els estils es filtrin a àrees no desitjades. Aquest problema sovint es transforma en un bucle autocomplert; els estils que teòricament tenen l'abast d'un element o classe comencen a aparèixer on no pertanyen. Això obliga el desenvolupador a crear selectors encara més específics per anul·lar els estils filtrats, que després anul·len accidentalment els estils globals, etc. Les convencions de noms de classe rígides, com ara BEM, són una solució teòrica a aquest problema. La metodologia BEM (Block, Element, Modifier) és una forma sistemàtica d'anomenar classes CSS per garantir la reutilització i l'estructura dels fitxers CSS. Convencions de denominació com aquesta poden reduir la càrrega cognitiva aprofitant el llenguatge del domini per descriure els elements i el seu estat, i si s'implementa correctament, pot facilitar el manteniment dels estils per a aplicacions grans. Al món real, però, no sempre funciona així. Les prioritats poden canviar, i amb el canvi, la implementació es torna inconsistent. Els petits canvis a l'estructura HTML poden requerir moltes revisions de noms de classe CSS. Amb les aplicacions frontals altament interactives, els noms de classe que segueixen el patró BEM poden arribar a ser llargs i difícils de manejar (p. ex., app-user-overview__status--is-authenticating), i no complir completament les regles de nomenclatura trenca l'estructura del sistema i neguen els seus beneficis. Tenint en compte aquests reptes, no és d'estranyar que els desenvolupadors hagin recorregut als frameworks, sent Tailwind el marc CSS més popular. En lloc d'intentar lluitar contra el que sembla una guerra d'especificitat invencible entre estils, és més fàcil renunciar a la cascada CSS i utilitzar eines que garanteixen un aïllament complet. Els desenvolupadors es basen més en les utilitats Com sabem que alguns desenvolupadors volen evitar els estils en cascada? És l'auge de les eines frontals "modernes", com els marcs CSS-in-JS, dissenyades específicament per a aquest propòsit. Treballar amb estils aïllats que estan estretament adaptats a components específics pot semblar una alenada d'aire fresc. Elimina la necessitat de posar nom a les coses, encara una de les tasques frontals més odiades i que consumeixen més temps, i permet als desenvolupadors ser productius sense entendre ni aprofitar completament els avantatges de l'herència CSS. Però abandonar la cascada CSS comporta els seus propis problemes. Per exemple, compondre estils en JavaScript requereix configuracions de construcció pesades i sovint condueix a estils que s'entremesclen de manera incòmode amb el marcatge de components o HTML. En lloc de considerar acuradament les convencions de nomenclatura, permetem que les eines de creació ens generin automàticament selectors i identificadors (p. ex., .jsx-3130221066), que requereixen que els desenvolupadors es mantinguin al dia amb un altre pseudollenguatge en si mateix. (Com si la càrrega cognitiva d'entendre què fan tots els efectes d'ús del vostre component ja no fos suficient!) L'abstracció addicional del treball d'anomenar classes a eines significa que la depuració bàsica sovint es limita a versions d'aplicacions específiques compilades per al desenvolupament, en lloc d'aprofitar les funcions natives del navegador que admeten la depuració en directe, com ara les eines per a desenvolupadors. És gairebé com si haguéssim de desenvolupar eines per depurar les eines que estem utilitzant per abstraure el que ja ofereix la web, tot per fugir del "dolor" d'escriure CSS estàndard. Afortunadament, les funcions CSS modernes no només fan que l'escriptura de CSS estàndard sigui més flexible, sinó que també donen als desenvolupadors com nosaltres molta més potència per gestionar la cascada i fer-la funcionar per a nosaltres. Les capes en cascada CSS són un gran exemple, però hi ha una altra característica que rep una sorprenent manca d'atenció, tot i que això està canviant ara que recentment s'ha convertit en compatible amb Baseline. El CSS @scope At-Rule Considero que la CSS @scope at-rule és una cura potencial per al tipus d'ansietat induïda per filtracions d'estil que hem cobert, que no ens obliga a comprometre els avantatges web natius per a les abstraccions i les eines de compilació addicionals. "La regla at-cs @scope us permet seleccionar elements en subarbres DOM específics, orientant-vos als elements amb precisió sense escriure selectors massa específics que són difícils d'anul·lar i sense acoblar els vostres selectors massa fortament a l'estructura DOM." - MDN
En altres paraules, podem treballar amb estils aïllats en casos concrets sense sacrificar l'herència, la cascada o fins i tot la separació bàsica de preocupacions.que ha estat un principi rector de llarga durada del desenvolupament frontal. A més, té una excel·lent cobertura del navegador. De fet, el Firefox 146 va afegir suport per a @scope al desembre, fent-lo compatible amb Baseline per primera vegada. Aquí teniu una comparació senzilla entre un botó que utilitza el patró BEM i la regla @scope:
La regla @scope permet una precisió amb menys complexitat. El desenvolupador ja no necessita crear límits amb noms de classe, que, al seu torn, els permet escriure selectors basats en elements HTML natius, eliminant així la necessitat de patrons de noms de classe CSS prescriptius. Simplement eliminant la necessitat de gestionar el nom de classe, @scope pot alleujar la por associada amb CSS en projectes grans.
Ús bàsic
Per començar, afegiu la regla @scope al vostre CSS i inseriu un selector d'arrel al qual s'abastaran els estils:
@àmbit (
Així, per exemple, si haguéssim d'abastar els estils a un element
@abast (navegació) { a { /* Estils d'enllaç dins de l'àmbit de navegació */ }
a:active { /* Estils d'enllaç actius */ }
a:active::before { /* Enllaç actiu amb pseudoelement per a un estil addicional */ }
@mitjana (amplada màxima: 768 píxels) { a { /* Ajustaments sensibles */ } } }
Això, per si sol, no és una característica innovadora. Tanmateix, es pot afegir un segon argument a l'àmbit per crear un límit inferior, definint de manera efectiva els punts inicials i finals de l'àmbit.
/* Qualsevol element dins d'ul no tindrà els estils aplicats */ @scope (nav) a (ul) { un { mida de la lletra: 14px; } }
Aquesta pràctica s'anomena abast de dona, i hi ha diversos enfocaments que es poden utilitzar, incloent una sèrie de selectors similars i molt específics acoblats estretament a l'estructura DOM, un pseudoselector :not o assignar noms de classe específics a elements dins del
Conclusió Els marcs CSS d'utilitat, com ara Tailwind, funcionen bé per a la creació de prototips i projectes més petits. Tanmateix, els seus beneficis disminueixen ràpidament quan s'utilitzen en projectes més grans que involucren més d'un parell de desenvolupadors. El desenvolupament de front-end s'ha tornat cada cop més complicat en els últims anys, i CSS no és una excepció. Tot i que la regla @scope no és una solució, pot reduir la necessitat d'eines complexes. Quan s'utilitza en lloc de, o al costat de la denominació de classe estratègica, @scope pot fer que sigui més fàcil i divertit escriure CSS que es pugui mantenir. Lectura addicional
CSS @scope (MDN) “CSS @scope”, Juan Diego Rodríguez (CSS-Tricks) Notes de la versió de Firefox 146 (Firefox) Suport del navegador (CanIUse) Marcs CSS populars (estat de CSS 2024) "La "C" en CSS: Cascade", Thomas Yip (CSS-Tricks) Introducció a BEM (obté BEM)
