Az alapvető CSS alapelveinek elsajátítása során megtanítják az embert moduláris, újrafelhasználható és leíró stílusok írására a karbantarthatóság biztosítása érdekében. De amikor a fejlesztők kapcsolatba kerülnek a valós alkalmazásokkal, gyakran lehetetlennek tűnik olyan felhasználói felületi funkciók hozzáadása anélkül, hogy a stílusok nem kívánt területekre szivárognának. Ez a probléma gyakran egy önbeteljesítő hurokba torkollik; azok a stílusok, amelyek elméletileg egy elemre vagy osztályra vonatkoznak, ott kezdenek megjelenni, ahol nem tartoznak ide. Ez arra kényszeríti a fejlesztőt, hogy még specifikusabb szelektorokat hozzon létre a kiszivárgott stílusok felülbírálásához, amelyek aztán véletlenül felülírják a globális stílusokat stb. A merev osztálynévkonvenciók, mint például a BEM, az egyik elméleti megoldás erre a kérdésre. A BEM (Block, Element, Modifier) módszer egy szisztematikus módszer a CSS-osztályok elnevezésére a CSS-fájlokon belüli újrafelhasználhatóság és struktúra biztosítása érdekében. Az ehhez hasonló elnevezési konvenciók csökkenthetik a kognitív terhelést azáltal, hogy a tartományi nyelvet felhasználják az elemek és állapotuk leírására, és ha helyesen implementálják, könnyebben karbantarthatók a nagy alkalmazások stílusai. A való világban azonban ez nem mindig működik így. A prioritások változhatnak, és a változtatással a végrehajtás következetlenné válik. A HTML-struktúra kis módosításai sok CSS-osztálynév-változtatást igényelhetnek. A rendkívül interaktív előtér-alkalmazásoknál a BEM-mintát követő osztálynevek hosszúak és nehézkesek lehetnek (pl. app-user-overview__status--is-authenticating), és az elnevezési szabályok teljes be nem tartása megbontja a rendszer szerkezetét, és ezáltal elveszíti előnyeit. Tekintettel ezekre a kihívásokra, nem csoda, hogy a fejlesztők a keretrendszerek felé fordultak, a Tailwind a legnépszerűbb CSS-keretrendszer. Ahelyett, hogy megpróbálnánk megvívni egy megnyerhetetlennek tűnő sajátosságháborút a stílusok között, könnyebb lemondani a CSS Cascade-ról, és olyan eszközöket használni, amelyek garantálják a teljes elszigeteltséget. A fejlesztők jobban támaszkodnak a segédprogramokra Honnan tudhatjuk, hogy egyes fejlesztők szívesen kerülik a lépcsőzetes stílusokat? Ez a „modern” front-end eszközök – például a CSS-in-JS keretrendszerek – térnyerése, amelyet kifejezetten erre a célra terveztek. Egy lélegzetvételnyi friss levegőnek tűnhet, ha olyan elszigetelt stílusokkal dolgozik, amelyek szorosan hozzá vannak kötve bizonyos összetevőkhöz. Megszünteti a dolgok elnevezésének szükségességét – még mindig az egyik legutáltabb és legidőigényesebb front-end feladat –, és lehetővé teszi a fejlesztők számára, hogy produktívak legyenek anélkül, hogy teljesen megértenék vagy kihasználnák a CSS-öröklés előnyeit. A CSS Cascade elhagyása azonban megvan a maga problémája. Például a stílusok JavaScriptben való összeállítása nehéz összeállítási konfigurációkat igényel, és gyakran vezet ahhoz, hogy a stílusok kínosan keveredjenek a komponensjelöléssel vagy a HTML-lel. A gondosan megfontolt elnevezési konvenciók helyett lehetővé tesszük az építőeszközök számára, hogy automatikusan generáljanak kiválasztókat és azonosítókat (pl. .jsx-3130221066), ami megköveteli a fejlesztőktől, hogy lépést tartsanak egy újabb pszeudonyelvvel. (Mintha nem lenne elég az a kognitív terhelés, hogy megértsd, mit tesz az összetevő összes használati hatása!) Az osztályok elnevezésének további elvonatkoztatása a szerszámozással azt jelenti, hogy az alapvető hibakeresés gyakran csak bizonyos alkalmazásverziókra van korlátozva, amelyeket fejlesztésre fordítottak, ahelyett, hogy az élő hibakeresést támogató natív böngészőfunkciókat, például a Fejlesztői eszközöket kihasználnák. Szinte olyan, mintha eszközöket kellene kifejlesztenünk az általunk használt eszközök hibakeresésére, hogy elvonatkoztassunk arról, amit a web már kínál – mindezt azért, hogy elkerüljük a szabványos CSS-írás „fájdalmát”. Szerencsére a modern CSS-funkciók nemcsak rugalmasabbá teszik a szabványos CSS-írást, hanem a hozzánk hasonló fejlesztőknek is sokkal több erőt adnak a kaszkád kezeléséhez és számunkra. A CSS Cascade Layers nagyszerű példa, de van egy másik funkció, amely meglepően figyelmen kívül hagyja – bár ez most megváltozik, mivel nemrégiben az alapvonallal kompatibilissé vált. A CSS @scope At-Rule Úgy gondolom, hogy a CSS @scope at-szabály egy lehetséges gyógyír a stílus-szivárgás által kiváltott szorongásra, amelyről már szó volt, és amely nem kényszerít bennünket arra, hogy a natív webes előnyöket az absztrakciók és az extra építési eszközök miatt kompromittáljuk. "A @scope CSS at-szabály lehetővé teszi, hogy elemeket jelöljön ki meghatározott DOM-alfákban, pontosan célozva az elemeket anélkül, hogy túlságosan specifikus, nehezen felülbírálható kijelölőket írna, és anélkül, hogy a kiválasztókat túl szorosan összekapcsolná a DOM-struktúrával." (MDN)
Más szavakkal, különálló stílusokkal dolgozhatunk bizonyos esetekben anélkül, hogy feláldoznánk az öröklődést, a lépcsőzetességet vagy akár az alapvető szempontok szétválasztását.ez a front-end fejlesztés régóta fennálló vezérelve. Ráadásul kiváló böngészőlefedettséggel rendelkezik. Valójában a Firefox 146 decemberben hozzáadta a @scope támogatását, így először lett Baseline kompatibilis. Íme egy egyszerű összehasonlítás a BEM mintát használó gombok és a @scope szabály között:
A @scope szabály kevésbé bonyolult pontosságot tesz lehetővé. A fejlesztőnek már nem kell határokat létrehoznia osztálynevek használatával, ami viszont lehetővé teszi számukra, hogy natív HTML-elemeken alapuló szelektorokat írjanak, így nincs szükség előíró CSS-osztálynévmintákra. Azáltal, hogy egyszerűen megszünteti az osztálynév-kezelés szükségességét, a @scope enyhítheti a CSS-hez kapcsolódó félelmet a nagy projektekben.
Alapvető használat
A kezdéshez adja hozzá a @scope szabályt a CSS-hez, és szúrjon be egy gyökérválasztót, amelyhez a stílusok hatókörbe kerülnek:
@scope (
Például, ha a stílusokat egy
@scope (nav) { a { /* Linkstílusok a navigációs hatókörön belül */ }
a:active { /* Aktív linkstílusok */}
a:active::before { /* Aktív hivatkozás pszeudoelemmel az extra stílusért */ }
@média (max. szélesség: 768 képpont) { a { /* Reszponzív korrekciók */ } } }
Ez önmagában nem egy átütő jellemző. Azonban egy második argumentum hozzáadható a hatókörhöz egy alsó határ létrehozása érdekében, amely hatékonyan meghatározza a hatókör kezdő- és végpontját.
/* Az ul-on belüli bármely elemre nem alkalmazzák a stílusokat */ @scope (nav) to (ul) { a { betűméret: 14 képpont; } }
Ezt a gyakorlatot fánk hatókörének nevezik, és többféle megközelítés is használható, beleértve a hasonló, nagyon specifikus szelektorok sorozatát, amelyek szorosan kapcsolódnak a DOM-struktúrához, egy :not pszeudo-szelektort, vagy adott osztálynevek hozzárendelését a
/* Az
Következtetés A segédprogram-első CSS-keretrendszerek, például a Tailwind, jól működnek prototípus-készítéshez és kisebb projektekhez. Előnyük azonban gyorsan csökken, ha nagyobb projektekben használják, amelyekben több fejlesztő vesz részt. A front-end fejlesztés az elmúlt néhány évben egyre bonyolultabbá vált, és ez alól a CSS sem kivétel. Bár a @scope szabály nem gyógyír mindenre, csökkentheti az összetett szerszámok szükségességét. Ha stratégiai osztályelnevezés helyett vagy mellett használjuk, a @scope egyszerűbbé és szórakoztatóbbá teheti a karbantartható CSS írását. További olvasás
CSS @scope (MDN) „CSS @scope”, Juan Diego Rodríguez (CSS-trükkök) Firefox 146 kibocsátási megjegyzések (Firefox) Böngésző támogatás (CanIUse) Népszerű CSS-keretrendszerek (CSS 2024 állapota) „A „C” a CSS-ben: Cascade”, Thomas Yip (CSS-trükkök) Bevezetés a BEM-be (BEM beszerzése)
