CSS:n perusperiaatteita opetettaessa opetetaan kirjoittamaan modulaarisia, uudelleenkäytettäviä ja kuvailevia tyylejä ylläpidettävyyden varmistamiseksi. Mutta kun kehittäjät liittyvät tosielämän sovelluksiin, käyttöliittymäominaisuuksien lisääminen tuntuu usein mahdottomalta ilman, että tyylejä vuotaa tahattomille alueille. Tämä ongelma muuttuu usein lumipalloksi itseään toteuttavaksi silmukaksi; tyylit, jotka on teoreettisesti rajattu yhteen elementtiin tai luokkaan, alkavat näkyä siellä, missä ne eivät kuulu. Tämä pakottaa kehittäjän luomaan vielä tarkempia valitsimia ohittamaan vuotaneet tyylit, jotka sitten vahingossa ohittavat globaalit tyylit ja niin edelleen. Jäykät luokan nimikäytännöt, kuten BEM, ovat yksi teoreettinen ratkaisu tähän ongelmaan. BEM (Block, Element, Modifier) -metodologia on systemaattinen tapa nimetä CSS-luokkia uudelleenkäytettävyyden ja rakenteen varmistamiseksi CSS-tiedostoissa. Tällaiset nimeämiskäytännöt voivat vähentää kognitiivista kuormitusta hyödyntämällä toimialueen kieltä kuvaamaan elementtejä ja niiden tilaa, ja jos ne toteutetaan oikein, ne voivat helpottaa suurten sovellusten tyylien ylläpitoa. Todellisessa maailmassa se ei kuitenkaan aina mene niin. Prioriteetit voivat muuttua, ja muutoksen myötä toteutus muuttuu epäjohdonmukaiseksi. Pienet muutokset HTML-rakenteeseen voivat vaatia useita CSS-luokan nimien muutoksia. Erittäin interaktiivisissa käyttöliittymäsovelluksissa BEM-mallia noudattavista luokkien nimistä voi tulla pitkiä ja hankalia (esim. app-user-overview__status--is-authenticating), ja nimeämissääntöjen noudattamatta jättäminen rikkoo järjestelmän rakenteen, mikä tekee tyhjäksi sen edut. Nämä haasteet huomioon ottaen ei ole ihme, että kehittäjät ovat kääntyneet kehyksien puoleen, sillä Tailwind on suosituin CSS-kehys. Sen sijaan, että yritetään taistella voittamattomalta näyttävää tyylien välistä erityissotaa, on helpompi luopua CSS-kaskadista ja käyttää työkaluja, jotka takaavat täydellisen eristäytymisen. Kehittäjät oppivat enemmän apuohjelmista Mistä tiedämme, että jotkut kehittäjät haluavat välttää peräkkäisiä tyylejä? Se on "modernien" käyttöliittymätyökalujen, kuten CSS-in-JS -kehysten, nousu, joka on suunniteltu erityisesti tähän tarkoitukseen. Työskentely yksittäisten tyylien kanssa, jotka on tiukasti sidottu tiettyihin komponentteihin, voi tuntua raitista ilmaa. Se poistaa tarpeen nimetä asioita – edelleen yksi vihatuimmista ja aikaavievimmistä käyttöliittymätehtävistä – ja antaa kehittäjille mahdollisuuden olla tuottavia ymmärtämättä täysin tai hyödyntämättä CSS-perinnön etuja. Mutta CSS Cascaden luopumiseen liittyy omat ongelmansa. Esimerkiksi tyylien luominen JavaScriptissä vaatii raskaita kokoonpanomäärityksiä ja johtaa usein tyylien hankaluuteen sekoittumiseen komponenttimerkintöjen tai HTML:n kanssa. Huolellisesti harkittujen nimeämiskäytäntöjen sijaan annamme rakennustyökaluille mahdollisuuden luoda automaattisesti valitsimia ja tunnisteita puolestamme (esim. .jsx-3130221066), mikä edellyttää kehittäjien pysymistä toisessa pseudokielessä sinänsä. (Ikään kuin kognitiivinen kuormitus ymmärtää, mitä kaikki komponenttisi useEffects tekevät, ei olisi jo tarpeeksi!) Luokkien nimeämisen jatkaminen työkaluihin tarkoittaa, että perusvirheenkorjaus rajoittuu usein tiettyihin kehitystä varten kootuihin sovellusversioihin sen sijaan, että hyödynnettäisiin selaimen alkuperäisiä ominaisuuksia, jotka tukevat live-virheenkorjausta, kuten kehittäjätyökaluja. On melkein kuin meidän on kehitettävä työkaluja sellaisten työkalujen virheenkorjaukseen, joita käytämme verkon jo tarjoamien asioiden abstraktioimiseksi – kaikki vain siksi, että pääsisimme pakoon standardi-CSS:n kirjoittamisen "tuskaa". Onneksi nykyaikaiset CSS-ominaisuudet eivät ainoastaan tee standardi-CSS:n kirjoittamisesta joustavampaa, vaan antavat myös meidän kaltaisillemme kehittäjille paljon enemmän valtaa hallita kaskadia ja saada se toimimaan puolestamme. CSS Cascade Layers on loistava esimerkki, mutta on toinen ominaisuus, joka saa yllättävän huomion puutteen – vaikka se on muuttumassa nyt, kun siitä on hiljattain tullut Baseline-yhteensopiva. CSS @scope At-Rule Pidän CSS:n @scope at-sääntöä mahdollisena parannuskeinona sellaiseen tyylivuodon aiheuttamaan ahdistukseen, jota olemme käsitelleet. Se ei pakota meitä tinkimään natiiviverkon eduista abstraktioille ja ylimääräisille rakennustyökaluille. "@scope CSS at-säännön avulla voit valita elementtejä tietyistä DOM-alipuista ja kohdistaa elementteihin tarkasti kirjoittamatta liian erityisiä valitsimia, joita on vaikea ohittaa, ja kytkemättä valitsimia liian tiukasti DOM-rakenteeseen." - MDN
Toisin sanoen voimme työskennellä yksittäisten tyylien kanssa tietyissä tapauksissa tinkimättä perinnöllisyydestä, peräkkäisyydestä tai jopa huolenaiheiden peruserottelusta.se on ollut pitkäaikainen ohjausperiaate etupään kehittämisessä. Lisäksi sillä on erinomainen selaimen kattavuus. Itse asiassa Firefox 146 lisäsi @scope-tuen joulukuussa, mikä teki siitä Baseline-yhteensopivan ensimmäistä kertaa. Tässä on yksinkertainen vertailu BEM-kuviota käyttävän painikkeen ja @scope-säännön välillä:
@scope-sääntö mahdollistaa tarkkuuden ja vähemmän monimutkaisuuden. Kehittäjän ei enää tarvitse luoda rajoja luokkanimien avulla, mikä puolestaan antaa heille mahdollisuuden kirjoittaa valitsimia natiivien HTML-elementtien perusteella, mikä eliminoi ohjeellisten CSS-luokan nimimallien tarpeen. Yksinkertaisesti poistamalla luokan nimenhallinnan tarpeen @scope voi lievittää CSS:ään liittyvää pelkoa suurissa projekteissa.
Peruskäyttö
Aloita lisäämällä @scope-sääntö CSS:ään ja lisäämällä juurivalitsin, johon tyylit rajataan:
@scope (
Jos siis esimerkiksi laajennamme tyylejä
@scope (nav) { a { /* Linkkityylit navigointialueen sisällä */ }
a:active { /* Aktiiviset linkkityylit */ }
a:active::before { /* Aktiivinen linkki pseudoelementillä lisätyyliä varten */ }
@media (enimmäisleveys: 768 kuvapistettä) { a { /* Responsiiviset säädöt */ } } }
Tämä ei sinänsä ole uraauurtava ominaisuus. Toinen argumentti voidaan kuitenkin lisätä laajuuteen alarajan luomiseksi, mikä määrittää tehokkaasti laajuuden aloitus- ja loppupisteet.
/* ul:n sisällä oleviin elementteihin ei käytetä tyylejä */ @scope (nav) - (ul) { a { fonttikoko: 14px; } }
Tätä käytäntöä kutsutaan donut-scopingiksi, ja siinä voidaan käyttää useita lähestymistapoja, mukaan lukien sarja samanlaisia, erittäin spesifisiä valitsimia, jotka on kytketty tiukasti DOM-rakenteeseen, :not pseudo-valitsin tai tiettyjen luokkanimien antaminen -elementeille
Johtopäätös Utility-first-CSS-kehykset, kuten Tailwind, toimivat hyvin prototyyppien valmistuksessa ja pienemmissä projekteissa. Niiden hyödyt kuitenkin pienenevät nopeasti, kun niitä käytetään suuremmissa projekteissa, joissa on enemmän kuin pari kehittäjää. Etupään kehitys on muuttunut viime vuosina yhä monimutkaisemmaksi, eikä CSS ole poikkeus. Vaikka @scope-sääntö ei ole parannuskeino, se voi vähentää monimutkaisten työkalujen tarvetta. Kun @scopea käytetään strategisen luokkanimeämisen sijasta tai rinnalla, se voi tehdä ylläpidettävän CSS:n kirjoittamisesta helpompaa ja hauskempaa. Lue lisää
CSS @scope (MDN) "CSS @scope", Juan Diego Rodríguez (CSS-Tricks) Firefox 146:n julkaisutiedot (Firefox) Selaintuki (CanIUse) Suositut CSS-kehykset (CSS 2024:n tila) "C" CSS:ssä: Cascade", Thomas Yip (CSS-Tricks) BEM-esittely (hanki BEM)
