Kapag natutunan ang mga prinsipyo ng pangunahing CSS, tinuturuan ang isa na magsulat ng mga modular, magagamit muli, at mapaglarawang mga istilo upang matiyak ang pagiging mapanatili. Ngunit kapag ang mga developer ay naging kasangkot sa mga real-world na application, kadalasan ay parang imposibleng magdagdag ng mga feature ng UI nang walang mga istilong tumutulo sa mga hindi sinasadyang lugar. Ang isyung ito ay madalas na nag-snowball sa isang self-fulfilling loop; ang mga istilong ayon sa teorya ay sumasaklaw sa isang elemento o klase ay nagsisimulang lumabas kung saan hindi sila kabilang. Pinipilit nito ang developer na gumawa ng mas partikular na mga tagapili para i-override ang mga leaked na istilo, na pagkatapos ay aksidenteng na-override ang mga pandaigdigang istilo, at iba pa. Ang mga mahigpit na kombensiyon ng pangalan ng klase, gaya ng BEM, ay isang teoretikal na solusyon sa isyung ito. Ang pamamaraang BEM (Block, Element, Modifier) ay isang sistematikong paraan ng pagbibigay ng pangalan sa mga klase ng CSS upang matiyak ang muling paggamit at istruktura sa loob ng mga CSS file. Ang pagbibigay ng pangalan sa mga convention na tulad nito ay maaaring mabawasan ang cognitive load sa pamamagitan ng paggamit ng domain language upang ilarawan ang mga elemento at ang kanilang estado, at kung ipinatupad nang tama, ay maaaring gawing mas madaling mapanatili ang mga istilo para sa malalaking application. Sa totoong mundo, gayunpaman, hindi ito palaging gumagana nang ganoon. Maaaring magbago ang mga priyoridad, at sa pagbabago, nagiging hindi pare-pareho ang pagpapatupad. Ang maliliit na pagbabago sa istruktura ng HTML ay maaaring mangailangan ng maraming pagbabago sa pangalan ng klase ng CSS. Sa mga napaka-interactive na front-end na application, ang mga pangalan ng klase na sumusunod sa pattern ng BEM ay maaaring maging mahaba at mahirap gamitin (hal., app-user-overview__status--ay-authenticating), at hindi ganap na sumunod sa mga panuntunan sa pagbibigay ng pangalan ay sumisira sa istruktura ng system, at sa gayon ay tinatanggihan ang mga benepisyo nito. Dahil sa mga hamong ito, hindi nakakagulat na ang mga developer ay bumaling sa mga framework, ang Tailwind ang pinakasikat na CSS framework. Sa halip na subukang labanan ang tila hindi mapanalunan na partikular na digmaan sa pagitan ng mga istilo, mas madaling sumuko sa CSS Cascade at gumamit ng mga tool na ginagarantiyahan ang kumpletong paghihiwalay. Ang mga Nag-develop ay Higit na Naniniwala sa Mga Utility Paano natin malalaman na ang ilang mga developer ay masigasig sa pag-iwas sa mga naka-cascade na istilo? Ito ay ang pagtaas ng "modernong" front-end tooling — tulad ng CSS-in-JS frameworks — na partikular na idinisenyo para sa layuning iyon. Ang pagtatrabaho sa mga nakahiwalay na istilo na mahigpit na saklaw sa mga partikular na bahagi ay maaaring magmukhang isang hininga ng sariwang hangin. Tinatanggal nito ang pangangailangang pangalanan ang mga bagay — isa pa rin sa pinakakinasusuklaman at nakakaubos ng oras sa harap na mga gawain — at nagbibigay-daan sa mga developer na maging produktibo nang hindi lubos na nauunawaan o nakikinabang sa mga benepisyo ng CSS inheritance. Ngunit ang pagtanggal sa CSS Cascade ay may sarili nitong mga problema. Halimbawa, ang pagbubuo ng mga istilo sa JavaScript ay nangangailangan ng mabibigat na configuration ng build at kadalasang humahantong sa mga istilong awkward na nakikihalo sa component markup o HTML. Sa halip na maingat na isaalang-alang ang mga convention sa pagbibigay ng pangalan, pinapayagan namin ang pagbuo ng mga tool upang awtomatikong bumuo ng mga selector at identifier para sa amin (hal., .jsx-3130221066), na nangangailangan ng mga developer na makipagsabayan sa isa pang pseudo-language sa loob at sa sarili nito. (Para bang hindi pa sapat ang cognitive load ng pag-unawa kung ano ang ginagawa ng lahat ng useEffects ng iyong component!) Ang karagdagang pag-abstract sa trabaho ng pagbibigay ng pangalan sa mga klase sa tooling ay nangangahulugan na ang pangunahing pag-debug ay kadalasang napipilitan sa mga partikular na bersyon ng application na pinagsama-sama para sa pag-unlad, sa halip na gamitin ang mga native na feature ng browser na sumusuporta sa live na pag-debug, gaya ng Developer Tools. Ito ay halos tulad ng kailangan naming bumuo ng mga tool upang i-debug ang mga tool na ginagamit namin upang i-abstract kung ano ang ibinibigay na ng web — lahat para sa pagtakas sa "sakit" ng pagsusulat ng karaniwang CSS. Sa kabutihang-palad, ang mga modernong tampok ng CSS ay hindi lamang ginagawang mas flexible ang pagsusulat ng karaniwang CSS ngunit nagbibigay din sa mga developer na tulad namin ng higit na kapangyarihan upang pamahalaan ang cascade at gawin itong gumana para sa amin. Ang CSS Cascade Layers ay isang magandang halimbawa, ngunit may isa pang feature na nakakakuha ng nakakagulat na kakulangan ng atensyon — bagama't nagbabago iyon ngayon na kamakailan ay naging tugma sa Baseline. Ang CSS @scope At-Rule Itinuturing kong ang CSS @scope at-rule ay isang potensyal na lunas para sa uri ng style-leak-induced na pagkabalisa na aming tinakpan, isa na hindi pumipilit sa amin na ikompromiso ang mga native na bentahe sa web para sa mga abstraction at karagdagang tool sa pagbuo. “Ang @scope CSS at-rule ay nagbibigay-daan sa iyo na pumili ng mga elemento sa mga partikular na subtree ng DOM, tumpak na nagta-target ng mga elemento nang hindi nagsusulat ng mga masyadong partikular na tagapili na mahirap i-override, at nang hindi masyadong mahigpit na ikinakabit ang iyong mga selector sa istruktura ng DOM.”— MDN
Sa madaling salita, maaari tayong gumamit ng mga nakahiwalay na istilo sa mga partikular na pagkakataon nang hindi isinasakripisyo ang mana, pag-cascade, o kahit na ang pangunahing paghihiwalay ng mga alalahanin.iyon ay isang matagal nang gabay na prinsipyo ng front-end na pag-unlad. Dagdag pa, mayroon itong mahusay na saklaw ng browser. Sa katunayan, nagdagdag ang Firefox 146 ng suporta para sa @scope noong Disyembre, na ginagawa itong tugma sa Baseline sa unang pagkakataon. Narito ang isang simpleng paghahambing sa pagitan ng isang button gamit ang BEM pattern kumpara sa @scope na panuntunan:
Ang panuntunang @scope ay nagbibigay-daan para sa katumpakan na hindi gaanong kumplikado. Hindi na kailangan ng developer na gumawa ng mga hangganan gamit ang mga pangalan ng klase, na, sa turn, ay nagpapahintulot sa kanila na magsulat ng mga tagapili batay sa mga native na elemento ng HTML, sa gayon ay inaalis ang pangangailangan para sa mga prescriptive na CSS class name patterns. Sa simpleng pag-aalis ng pangangailangan para sa pamamahala ng pangalan ng klase, mapapawi ng @scope ang takot na nauugnay sa CSS sa malalaking proyekto.
Pangunahing Paggamit
Upang makapagsimula, idagdag ang @scope na panuntunan sa iyong CSS at maglagay ng root selector kung aling mga istilo ang sasakupin:
@scope (
Kaya, halimbawa, kung sasakupin natin ang mga istilo sa isang
@scope (nav) { isang { /* Mga istilo ng link sa loob ng saklaw ng nav */ }
a:active { /* Active link styles */ }
a:active::before { /* Aktibong link na may pseudo-element para sa dagdag na istilo */ }
@media (max-width: 768px) { isang { /* Mga tumutugong pagsasaayos */ } } }
Ito, sa sarili nitong, ay hindi isang groundbreaking na tampok. Gayunpaman, maaaring magdagdag ng pangalawang argumento sa saklaw upang lumikha ng mas mababang hangganan, na epektibong tumukoy sa mga punto ng pagsisimula at pagtatapos ng saklaw.
/* Anumang elemento sa loob ng ul ay hindi mailalapat ang mga istilo */ @scope (nav) hanggang (ul) { isang { laki ng font: 14px; } }
Ang pagsasanay na ito ay tinatawag na donut scoping, at mayroong ilang mga diskarte na magagamit ng isa, kabilang ang isang serye ng mga katulad, lubos na partikular na mga tagapili na pinagsama nang mahigpit sa istruktura ng DOM, isang :not pseudo-selector, o pagtatalaga ng mga partikular na pangalan ng klase sa mga elemento sa loob ng
Konklusyon Utility-first CSS frameworks, gaya ng Tailwind, ay gumagana nang maayos para sa prototyping at mas maliliit na proyekto. Ang kanilang mga benepisyo ay mabilis na nababawasan, gayunpaman, kapag ginamit sa mas malalaking proyekto na kinasasangkutan ng higit sa isang pares ng mga developer. Ang pag-unlad ng front-end ay lalong naging kumplikado sa nakalipas na ilang taon, at ang CSS ay walang pagbubukod. Bagama't ang panuntunang @scope ay hindi isang lunas-lahat, maaari nitong bawasan ang pangangailangan para sa kumplikadong tooling. Kapag ginamit bilang kapalit ng, o kasama ng estratehikong pagpapangalan ng klase, maaaring gawing mas madali at mas masaya ng @scope ang pagsulat ng napapanatiling CSS. Karagdagang Pagbasa
CSS @scope (MDN) “CSS @scope”, Juan Diego Rodríguez (CSS-Tricks) Mga Tala sa Paglabas ng Firefox 146 (Firefox) Suporta sa Browser (CanIUse) Mga Sikat na CSS Framework (State of CSS 2024) "Ang "C" sa CSS: Cascade", Thomas Yip (CSS-Tricks) Panimula ng BEM (Kunin ang BEM)
