CSS-i põhiprintsiipide õppimisel õpetatakse hooldatavuse tagamiseks kirjutama modulaarseid, korduvkasutatavaid ja kirjeldavaid stiile. Kuid kui arendajad hakkavad tegelema reaalsete rakendustega, tundub sageli võimatu lisada kasutajaliidese funktsioone ilma stiilide lekkimiseta soovimatutesse piirkondadesse. See probleem läheb sageli isetäituvaks ahelaks; stiilid, mis on teoreetiliselt seotud ühe elemendi või klassiga, hakkavad ilmuma sinna, kus nad ei kuulu. See sunnib arendajat looma veelgi spetsiifilisemaid selektoreid, et alistada lekkinud stiilid, mis siis kogemata alistavad globaalsed stiilid jne. Selle probleemi üheks teoreetiliseks lahenduseks on jäigad klassinimekokkulepped, nagu BEM. BEM (Block, Element, Modifier) metoodika on süstemaatiline viis CSS-klasside nimetamiseks, et tagada CSS-failide korduvkasutatavus ja struktuur. Sellised nimekokkulepped võivad vähendada kognitiivset koormust, kasutades domeenikeelt elementide ja nende oleku kirjeldamiseks, ning kui see on õigesti rakendatud, võivad need muuta suurte rakenduste stiilide hooldamise lihtsamaks. Reaalses maailmas see aga alati nii ei lähe. Prioriteedid võivad muutuda ja muutustega muutub rakendamine ebajärjekindlaks. Väikesed muudatused HTML-i struktuuris võivad nõuda palju CSS-klassi nimede muudatusi. Väga interaktiivsete esiotsarakenduste puhul võivad BEM-mustrit järgivad klassinimed muutuda pikaks ja kohmakaks (nt app-user-overview__status--is-authenticing) ning nimede andmise reeglite mittejärgimine rikub süsteemi struktuuri, muutes seeläbi selle eelised olematuks. Arvestades neid väljakutseid, pole ime, et arendajad on pöördunud raamistike poole, millest Tailwind on kõige populaarsem CSS-i raamistik. Selle asemel, et võidelda stiilidevahelise võitmatu spetsiifilisuse sõjaga, on lihtsam loobuda CSS-kaskaadist ja kasutada tööriistu, mis tagavad täieliku isolatsiooni. Arendajad kasutavad rohkem utiliite Kuidas me teame, et mõned arendajad soovivad vältida kaskaadstiile? See on "kaasaegse" esiotsa tööriistade, nagu CSS-in-JS raamistikud, tõus, mis on spetsiaalselt selleks otstarbeks loodud. Töötamine isoleeritud stiilidega, mis on tihedalt seotud konkreetsete komponentidega, võib tunduda värske õhu sõõm. See eemaldab vajaduse nimetada asju – see on endiselt üks vihatumaid ja aeganõudvamaid esiotsa ülesandeid – ning võimaldab arendajatel olla produktiivne ilma CSS-i pärimise eeliseid täielikult mõistmata või ära kasutamata. Kuid CSS Cascade'ist loobumisega kaasnevad oma probleemid. Näiteks stiilide koostamine JavaScriptis nõuab raskeid ehituskonfiguratsioone ja põhjustab sageli stiilide kohmakalt segunemist komponentide märgistuse või HTML-iga. Hoolikalt läbimõeldud nimetamisreeglite asemel lubame koostamistööriistadel meie jaoks automaatselt genereerida valijaid ja identifikaatoreid (nt .jsx-3130221066), mis nõuab, et arendajad oleksid kursis veel ühe pseudokeelega. (Nagu poleks kognitiivsest koormusest mõistmine, mida kõik teie komponendi kasutusefektid teevad, veel piisavaks!) Klasside nimetamise töö edasine abstraktsioon tööriistadeks tähendab, et põhisilumine piirdub sageli arenduse jaoks koostatud konkreetsete rakenduste versioonidega, selle asemel, et kasutada brauseri natiivseid funktsioone, mis toetavad reaalajas silumist, nagu arendaja tööriistad. Peaaegu nagu peaksime välja töötama tööriistu, et siluda tööriistu, mida kasutame veebi juba pakutava abstraktsiooniks – seda kõike selleks, et põgeneda standardse CSS-i kirjutamise "valu" eest. Õnneks ei muuda kaasaegsed CSS-i funktsioonid mitte ainult standardse CSS-i kirjutamist paindlikumaks, vaid annavad meiesugustele arendajatele ka palju rohkem jõudu kaskaadi haldamiseks ja selle meie heaks tööle panemiseks. CSS-i kaskaadikihid on suurepärane näide, kuid on veel üks funktsioon, mis pälvib üllatavalt vähe tähelepanu – kuigi see muutub nüüd, kuna see on hiljuti põhitasemega ühilduvaks saanud. CSS @scope At-Rule Arvan, et CSS-i @scope at-reegel on potentsiaalne ravi stiililekkest põhjustatud ärevuse vastu, mida oleme käsitlenud. See ei sunni meid tegema kompromisse veebipõhiste eeliste osas abstraktsioonide ja täiendavate ehitustööriistade osas. "@scope CSS-i reegel võimaldab teil valida elemente konkreetsetes DOM-i alampuudes, sihtides elemente täpselt ilma liiga spetsiifilisi valijaid, mida on raske alistada, ja ilma valijaid liiga tihedalt DOM-i struktuuriga sidumata." - MDN
Teisisõnu saame teatud juhtudel töötada isoleeritud stiilidega, ohverdamata pärimist, kaskaadi või isegi probleemide põhilist eraldamist.see on olnud esiotsa arendamise pikaajaline juhtpõhimõte. Lisaks on sellel suurepärane brauseri katvus. Tegelikult lisas Firefox 146 detsembris @scope'i toe, muutes selle esimest korda Baseline'iga ühilduvaks. Siin on lihtne võrdlus BEM-mustrit kasutava nupu ja @scope reegli vahel:
@scope reegel võimaldab täpsust väiksema keerukusega. Arendaja ei pea enam klassinimede abil piire looma, mis omakorda võimaldab neil kirjutada natiivsetel HTML-elementidel põhinevaid selektoreid, välistades seeläbi vajaduse ettekirjutavate CSS-klassi nimemustrite järele. Lihtsalt eemaldades vajaduse klassinimede haldamise järele, saab @scope leevendada suurtes projektides CSS-iga seotud hirmu.
Põhikasutus
Alustuseks lisage oma CSS-ile reegel @scope ja sisestage juurvalija, mille stiilid ulatuvad:
@scope (
Näiteks kui peaksime laadima elemendile
@scope (nav) { a { /* Lingistiilid navigeerimisulatuses */ }
a:active { /* Aktiivsed lingi stiilid */ }
a:active::before { /* Aktiivne link pseudoelemendiga lisastiili jaoks */ }
@meedia (maksimaalne laius: 768 pikslit) { a { /* Kohandused */ } } }
See iseenesest ei ole murranguline funktsioon. Siiski saab ulatusele lisada teise argumendi, et luua alumine piir, mis määrab tõhusalt ulatuse algus- ja lõpp-punkti.
/* Ul-i sees olevatele elementidele ei rakendata stiile */ @scope (nav) kuni (ul) { a { fondi suurus: 14 pikslit; } }
Seda praktikat nimetatakse sõõriku ulatuse määramiseks ja seal on mitu lähenemisviisi, sealhulgas rida sarnaseid, väga spetsiifilisi selektoreid, mis on tihedalt seotud DOM-i struktuuriga, pseudovalija :not või konkreetsete klassinimede määramine elementidele erineva CSS-i käsitlemiseks. Vaatamata nendele muudele lähenemisviisidele on @scope meetod palju sisutihedam. Veelgi olulisem on see, et see hoiab ära katkiste stiilide ohu, kui klassinimed muutuvad või neid väärkasutatakse või kui HTML-i struktuuri muudetakse. Nüüd, kui @scope on Baseline'iga ühilduv, ei vaja me enam lahendusi! Saame seda ideed edasi viia mitme otsapiiriga, et luua "stiilikujuline kaheksa":
Järeldus Utiliidipõhised CSS-raamistikud, nagu Tailwind, töötavad hästi prototüüpide ja väiksemate projektide jaoks. Nende eelised vähenevad aga kiiresti, kui neid kasutatakse suuremates projektides, mis hõlmavad rohkem kui paar arendajat. Esiotsa arendamine on viimastel aastatel muutunud üha keerulisemaks ja CSS pole erand. Kuigi @scope reegel ei ole kõigele ravim, võib see vähendada vajadust keerukate tööriistade järele. Kui @scope'i kasutatakse strateegilise klassinimede määramise asemel või selle kõrval, võib see hooldatava CSS-i kirjutamise lihtsamaks ja lõbusamaks muuta. Edasine Lugemine
CSS @scope (MDN) "CSS @scope", Juan Diego Rodríguez (CSS-Tricks) Firefox 146 väljalaskemärkmed (Firefox) Brauseri tugi (CanIUse) Populaarsed CSS-i raamistikud (CSS 2024 olek) "C" CSS-is: kaskaad", Thomas Yip (CSS-trikid) BEM-i tutvustus (hankige BEM)
