Ko se učimo načel osnovnega CSS, se naučimo pisati modularne, ponovno uporabne in opisne sloge, da zagotovimo vzdržljivost. Ko pa se razvijalci začnejo ukvarjati z aplikacijami iz resničnega sveta, se pogosto zdi nemogoče dodati funkcije uporabniškega vmesnika, ne da bi slogi uhajali na nenamerna področja. Ta težava pogosto preide v samoizpolnjujočo se zanko; slogi, ki so teoretično omejeni na en element ali razred, se začnejo pojavljati tam, kjer ne sodijo. To prisili razvijalca, da ustvari še bolj specifične izbirnike za preglasitev razkritih slogov, ki nato pomotoma preglasijo globalne sloge itd. Toge konvencije o imenih razredov, kot je BEM, so ena od teoretičnih rešitev tega vprašanja. Metodologija BEM (Block, Element, Modifier) je sistematičen način poimenovanja razredov CSS za zagotovitev ponovne uporabe in strukture znotraj datotek CSS. Takšne konvencije o poimenovanju lahko zmanjšajo kognitivno obremenitev z uporabo domenskega jezika za opis elementov in njihovega stanja, in če so pravilno implementirane, lahko olajšajo vzdrževanje slogov za velike aplikacije. V resničnem svetu pa ne gre vedno tako. Prioritete se lahko spremenijo in s spremembo postane izvajanje nedosledno. Majhne spremembe strukture HTML lahko zahtevajo številne revizije imen razreda CSS. Z zelo interaktivnimi sprednjimi aplikacijami lahko imena razredov, ki sledijo vzorcu BEM, postanejo dolga in okorna (npr. app-user-overview__status--is-authenticating), neupoštevanje pravil poimenovanja v celoti pa poruši strukturo sistema in s tem izniči njegove prednosti. Glede na te izzive ni čudno, da so se razvijalci obrnili na ogrodja, pri čemer je Tailwind najbolj priljubljeno ogrodje CSS. Namesto da bi se poskušali boriti proti nečemu, kar se zdi nezmagljiva vojna specifičnosti med slogi, je lažje opustiti CSS Cascade in uporabiti orodja, ki zagotavljajo popolno izolacijo. Razvijalci se bolj zanašajo na pripomočke Kako vemo, da se nekateri razvijalci radi izogibajo kaskadnim slogom? To je vzpon "modernih" sprednjih orodij - kot so okviri CSS-in-JS - zasnovanih posebej za ta namen. Delo z izoliranimi slogi, ki so tesno povezani z določenimi komponentami, se lahko zdi kot dah svežega zraka. Odpravlja potrebo po poimenovanju stvari – še vedno eno izmed najbolj osovraženih in zamudnih opravil na sprednjem delu – in omogoča razvijalcem, da so produktivni, ne da bi v celoti razumeli ali izkoristili prednosti dedovanja CSS. Toda opustitev CSS Cascade ima svoje težave. Na primer, sestavljanje slogov v JavaScript zahteva obsežne konfiguracije gradnje in pogosto vodi do nerodnega mešanja slogov z oznakami komponent ali HTML. Namesto skrbno pretehtanih konvencij o poimenovanju dovolimo, da orodja za izdelavo samodejno ustvarijo izbirnike in identifikatorje za nas (npr. .jsx-3130221066), kar od razvijalcev zahteva, da sledijo še enemu psevdo-jeziku samemu po sebi. (Kot da kognitivna obremenitev razumevanja, kaj vse počnejo useEffects vaše komponente, še ne bi bila dovolj!) Nadaljnje abstrahiranje opravila poimenovanja razredov v orodja pomeni, da je osnovno odpravljanje napak pogosto omejeno na specifične različice aplikacije, prevedene za razvoj, namesto da bi izkoristile funkcije izvornega brskalnika, ki podpirajo odpravljanje napak v živo, kot so orodja za razvijalce. Skoraj tako, kot da bi morali razviti orodja za odpravljanje napak v orodjih, ki jih uporabljamo za abstrahiranje tega, kar splet že ponuja – vse zaradi pobega pred »bolečino« pisanja standardnega CSS. Na srečo sodobne funkcije CSS ne samo, da naredijo pisanje standardnega CSS bolj prilagodljivo, ampak tudi dajejo razvijalcem, kot smo mi, veliko več moči za upravljanje kaskade in omogočanje, da deluje za nas. CSS Cascade Layers so odličen primer, vendar obstaja še ena funkcija, ki ji presenetljivo primanjkuje pozornosti – čeprav se to zdaj spreminja, ko je pred kratkim postala združljiva z osnovno linijo. Pravilo CSS @scope At-Rule Menim, da je pravilo @scope at-rule CSS možno zdravilo za vrsto tesnobe zaradi uhajanja sloga, ki smo jo obravnavali, in ki nas ne prisili, da ogrozimo izvorne spletne prednosti za abstrakcije in dodatna orodja za gradnjo. »Pravilo @scope CSS at-rule vam omogoča, da izberete elemente v določenih poddrevesih DOM, natančno ciljate na elemente, ne da bi pisali preveč specifične izbirnike, ki jih je težko preglasiti, in ne da bi vaše izbirnike pretesno povezali s strukturo DOM.« — MDN
Z drugimi besedami, delamo lahko z izoliranimi slogi v določenih primerih, ne da bi pri tem žrtvovali dedovanje, kaskadiranje ali celo osnovno ločevanje pomislekovto je bilo dolgoletno vodilno načelo front-end razvoja. Poleg tega ima odlično pokritost brskalnika. Pravzaprav je Firefox 146 decembra dodal podporo za @scope, s čimer je prvič postal združljiv z Baseline. Tu je preprosta primerjava med gumbom, ki uporablja vzorec BEM, in pravilom @scope:
Pravilo @scope omogoča natančnost z manj zapletenosti. Razvijalcu ni več treba ustvarjati meja z uporabo imen razredov, kar jim posledično omogoča pisanje izbirnikov na podlagi izvornih elementov HTML, s čimer se odpravi potreba po predpisanih vzorcih imen razredov CSS. S preprosto odstranitvijo potrebe po upravljanju imen razredov lahko @scope zmanjša strah, povezan s CSS v velikih projektih.
Osnovna uporaba
Če želite začeti, dodajte pravilo @scope svojemu CSS in vstavite korenski izbirnik, ki bo obsegal sloge:
@scope (
Torej, na primer, če bi stile razširili na element
@scope (nav) { a { /* Slogi povezav v obsegu krmarjenja */ }
a:active { /* Aktivni slogi povezav */ }
a:active::before { /* Aktivna povezava s psevdoelementom za dodatno oblikovanje */ }
@media (max-width: 768px) { a { /* Odzivne prilagoditve */ } } }
To samo po sebi ni prelomna funkcija. Vendar pa lahko obsegu dodate drugi argument, da ustvarite spodnjo mejo, ki učinkovito definira začetno in končno točko obsega.
/* Noben element znotraj ul ne bo imel uporabljenih slogov */ @scope (nav) to (ul) { a { velikost pisave: 14px; } }
Ta praksa se imenuje določanje obsega krofov in obstaja več pristopov, ki bi jih lahko uporabili, vključno z nizom podobnih, zelo specifičnih izbirnikov, ki so tesno povezani s strukturo DOM, psevdoizbirnikom :not ali dodeljevanjem posebnih imen razredov elementom znotraj
Zaključek Utility-prva ogrodja CSS, kot je Tailwind, dobro delujejo za izdelavo prototipov in manjše projekte. Njihove prednosti pa se hitro zmanjšajo, če se uporabljajo v večjih projektih, ki vključujejo več kot nekaj razvijalcev. Front-end razvoj je v zadnjih nekaj letih postal vse bolj zapleten in CSS ni izjema. Čeprav pravilo @scope ni zdravilo za vse, lahko zmanjša potrebo po zapletenem orodju. Če se uporablja namesto ali poleg strateškega poimenovanja razredov, lahko @scope olajša in naredi bolj zabavno pisanje CSS-ja, ki ga je mogoče vzdrževati. Nadaljnje branje
CSS @scope (MDN) »CSS @scope«, Juan Diego Rodríguez (CSS-Tricks) Opombe ob izdaji Firefoxa 146 (Firefox) Podpora za brskalnik (CanIUse) Priljubljena ogrodja CSS (stanje CSS 2024) »C v CSS: Cascade«, Thomas Yip (CSS-Tricks) Predstavitev BEM (Pridobite BEM)
