Հիմնական CSS-ի սկզբունքները սովորելիս սովորեցնում են գրել մոդուլային, բազմակի օգտագործման և նկարագրական ոճեր՝ պահպանելու համար: Բայց երբ մշակողները ներգրավվում են իրական աշխարհի հավելվածների հետ, հաճախ անհնար է թվում ավելացնել UI-ի առանձնահատկությունները՝ առանց ոճերի արտահոսքի դեպի չնախատեսված տարածքներ: Այս խնդիրը հաճախ ձնագնդի վերածվում է ինքնիրագործվող հանգույցի. ոճերը, որոնք տեսականորեն ընդգրկված են մեկ տարրի կամ դասի վրա, սկսում են ցուցադրվել այնտեղ, որտեղ նրանք չեն պատկանում: Սա ստիպում է մշակողին ստեղծել ավելի կոնկրետ ընտրիչներ՝ արտահոսած ոճերը վերացնելու համար, որոնք այնուհետև պատահաբար անտեսում են գլոբալ ոճերը և այլն: Դասի անվանման կոշտ կոնվենցիաները, ինչպիսին է BEM-ը, այս հարցի տեսական լուծումներից մեկն է: BEM (Block, Element, Modifier) մեթոդոլոգիան CSS դասերի անվանման համակարգված միջոց է՝ CSS ֆայլերի ներսում կրկնակի օգտագործման և կառուցվածքի ապահովման համար: Անվանման նման պայմանագրերը կարող են նվազեցնել ճանաչողական բեռը՝ օգտագործելով տիրույթի լեզուն՝ նկարագրելու տարրերը և դրանց վիճակը, և եթե ճիշտ իրականացվեն, կարող են հեշտացնել ոճերը մեծ հավելվածների համար: Իրական աշխարհում, սակայն, միշտ չէ, որ այդպես է ստացվում: Առաջնահերթությունները կարող են փոխվել, և փոփոխության դեպքում իրականացումը դառնում է անհետևողական: HTML կառուցվածքի փոքր փոփոխությունները կարող են պահանջել բազմաթիվ CSS դասի անվան վերանայումներ: Բարձր ինտերակտիվ առջևի հավելվածների դեպքում դասերի անունները, որոնք հետևում են BEM օրինաչափությանը, կարող են դառնալ երկար և անգործունակ (օրինակ՝ app-user-overview__status--is-authenticating), և անվանման կանոններին ամբողջությամբ չպահպանելը խախտում է համակարգի կառուցվածքը՝ դրանով իսկ ժխտելով դրա առավելությունները: Հաշվի առնելով այս մարտահրավերները, զարմանալի չէ, որ մշակողները դիմել են շրջանակներին, քանի որ Tailwind-ը CSS-ի ամենահայտնի շրջանակն է: Ավելի հեշտ է հրաժարվել CSS Cascade-ից և օգտագործել այնպիսի գործիքներ, որոնք երաշխավորում են ամբողջական մեկուսացում, այլ ոչ թե փորձել պայքարել ոճերի միջև անհաղթելի յուրահատկությունների պատերազմում: Մշակողները ավելի շատ են հենվում կոմունալ ծառայությունների վրա Ինչպե՞ս գիտենք, որ որոշ մշակողներ ցանկանում են խուսափել կասկադային ոճերից: Դա «ժամանակակից» առջևի գործիքների վերելքն է, ինչպիսին է CSS-in-JS շրջանակները, որոնք հատուկ նախագծված են այդ նպատակով: Մեկուսացված ոճերի հետ աշխատելը, որոնք սերտորեն կապված են որոշակի բաղադրիչների հետ, կարող է թվալ թարմ օդի շունչ: Այն վերացնում է բաներ անվանելու անհրաժեշտությունը, որը դեռևս ամենաատելի և ժամանակատար առջևի խնդիրներից մեկն է, և թույլ է տալիս ծրագրավորողներին լինել արդյունավետ՝ առանց CSS ժառանգության առավելությունները լիովին հասկանալու կամ օգտագործելու: Սակայն CSS Կասկադից հրաժարվելն իր խնդիրներն ունի: Օրինակ, JavaScript-ում ոճեր կազմելը պահանջում է ծանր կառուցվածքային կոնֆիգուրացիաներ և հաճախ հանգեցնում է նրան, որ ոճերը անհարմար կերպով խառնվում են բաղադրիչի նշագրման կամ HTML-ի հետ: Մանրակրկիտ մտածված անվանման կոնվենցիաների փոխարեն՝ մենք թույլ ենք տալիս ստեղծել գործիքներ՝ մեզ համար ընտրիչներ և նույնացուցիչներ ավտոմատ ստեղծելու համար (օրինակ՝ .jsx-3130221066)՝ պահանջելով, որ մշակողները հետևեն ևս մեկ այլ կեղծ լեզվի և ինքնին: (Կարծես ճանաչողական ծանրաբեռնվածությունը հասկանալու համար, թե ինչ են անում ձեր բաղադրիչի բոլոր օգտագործման էֆեկտները, արդեն բավական չէ:) Դասերը գործիքավորելու աշխատանքի հետագա վերացականացումը նշանակում է, որ հիմնական վրիպազերծումը հաճախ սահմանափակվում է մշակման համար կազմված հատուկ հավելվածների տարբերակներով, այլ ոչ թե օգտագործելու հիմնական զննարկիչի գործառույթները, որոնք աջակցում են կենդանի կարգաբերումներին, ինչպիսիք են Developer Tools-ը: Մոտավորապես նման է, որ մենք պետք է մշակենք գործիքներ՝ վրիպազերծելու այն գործիքները, որոնք մենք օգտագործում ենք, որպեսզի վերացնենք այն, ինչ վեբն արդեն տրամադրում է. այս ամենը հանուն ստանդարտ CSS գրելու «ցավից» փախչելու: Բարեբախտաբար, CSS-ի ժամանակակից առանձնահատկությունները ոչ միայն դարձնում են ստանդարտ CSS գրելը ավելի ճկուն, այլ նաև մեզ նման ծրագրավորողներին տալիս են կասկադը կառավարելու և այն մեզ համար աշխատելու մեծ ուժ: CSS Cascade Layers-ը հիանալի օրինակ է, բայց կա ևս մեկ առանձնահատկություն, որը զարմանալիորեն ուշադրության պակաս է ստանում, թեև այն փոխվում է հիմա, երբ այն վերջերս դարձել է բազային համատեղելի: CSS @scope At-Rule Ես համարում եմ, որ CSS @scope at-rule-ը պոտենցիալ բուժում է ոճային արտահոսքի հետևանքով առաջացած անհանգստության համար, որը մենք լուսաբանել ենք, որը չի ստիպում մեզ զիջել հայրենի վեբ առավելությունները աբստրակցիաների և լրացուցիչ կառուցման գործիքների համար: «@scope CSS at-rule-ը թույլ է տալիս ընտրել տարրեր հատուկ DOM ենթածառերում՝ թիրախավորելով տարրերը, առանց գրելու չափազանց հատուկ ընտրիչներ, որոնք դժվար է անտեսել, և առանց ձեր ընտրիչները չափազանց ամուր միացնելու DOM կառուցվածքին»: - MDN:
Այլ կերպ ասած, մենք կարող ենք աշխատել մեկուսացված ոճերի հետ կոնկրետ դեպքերում՝ առանց ժառանգականության, կասկադի կամ նույնիսկ մտահոգությունների հիմնական տարանջատման։դա եղել է առջևի զարգացման երկարաժամկետ առաջնորդող սկզբունքը: Բացի այդ, այն ունի հիանալի բրաուզերի ծածկույթ: Փաստորեն, Firefox 146-ը դեկտեմբերին ավելացրեց @scope-ի աջակցությունը՝ այն առաջին անգամ համատեղելի դարձնելով Baseline-ի համար: Ահա մի պարզ համեմատություն կոճակի միջև, որն օգտագործում է BEM օրինակն ընդդեմ @scope կանոնի.
<ոճ> .button .button__text { /* button text styles */ } .button .button__icon { /* button icon styles */ } .button--primary { հիմնական կոճակի ոճեր */ }
<ոճ> @scope (.primary-button) { span:first-child { /* button text styles */ } span:last-child { /* կոճակի պատկերակի ոճեր */ } }
@scope կանոնը թույլ է տալիս ճշգրիտ լինել ավելի քիչ բարդությամբ: Մշակողն այլևս կարիք չունի սահմաններ ստեղծել՝ օգտագործելով դասերի անունները, ինչը, իր հերթին, թույլ է տալիս նրանց գրել ընտրիչներ՝ հիմնված բնիկ HTML տարրերի վրա՝ դրանով իսկ վերացնելով CSS դասի անվանման օրինաչափությունների անհրաժեշտությունը: Պարզապես հեռացնելով դասի անունների կառավարման անհրաժեշտությունը՝ @scope-ը կարող է մեղմել CSS-ի հետ կապված մեծ նախագծերի վախը: Հիմնական օգտագործումը Սկսելու համար ավելացրեք @scope կանոնը ձեր CSS-ում և տեղադրեք արմատային ընտրիչ, որի ոճերը կտարածվեն. @scope (<ընտրիչ>) { /* Ոճերը սահմանվում են դեպի <ընտրիչ> */ }
Այսպիսով, օրինակ, եթե մենք ոճերը ընդգրկում ենք
@scope (nav) { a { /* Հղման ոճերը նավի շրջանակում */ }
a:active { /* Ակտիվ հղման ոճեր */ }
a:active::before { /* Ակտիվ հղում կեղծ տարրով լրացուցիչ ոճավորման համար */ }
@media (առավելագույն լայնությունը՝ 768px) { a { /* Պատասխանատու ճշգրտումներ */ } } }
Սա, ինքնին, բեկումնային հատկանիշ չէ: Այնուամենայնիվ, երկրորդ արգումենտը կարող է ավելացվել շրջանակին՝ ավելի ցածր սահման ստեղծելու համար՝ արդյունավետորեն սահմանելով շրջանակի սկզբնական և վերջնակետերը:
/* ul-ի ներսում գտնվող ցանկացած տարր չի կիրառի ոճերը */ @scope (nav) մինչև (ul) { ա { տառաչափը՝ 14px; } }
Այս պրակտիկան կոչվում է բլիթ շրջանակներ, և կան մի քանի մոտեցումներ, որոնք կարելի է օգտագործել, ներառյալ մի շարք նմանատիպ, խիստ հատուկ ընտրիչներ, որոնք սերտորեն զուգակցված են DOM կառուցվածքին, :not pseudo-selector, կամ որոշակի դասերի անուններ հատկացնելով տարրերին
Եզրակացություն Կոմունալ առաջին CSS շրջանակները, ինչպիսիք են Tailwind-ը, լավ են աշխատում նախատիպերի և փոքր նախագծերի համար: Նրանց առավելությունները արագորեն նվազում են, սակայն, երբ օգտագործվում են ավելի մեծ նախագծերում, որոնցում ներգրավված են ավելի քան երկու մշակողներ: Front-end-ի մշակումն ավելի ու ավելի է բարդացել վերջին մի քանի տարիներին, և CSS-ը բացառություն չէ: Թեև @scope կանոնը ամեն ինչ բուժելու միջոց չէ, այն կարող է նվազեցնել բարդ գործիքների կարիքը: Երբ օգտագործվում է դասի ռազմավարական անվանման փոխարեն կամ կողքին, @scope-ը կարող է հեշտացնել և ավելի զվարճալի դարձնել պահպանելի CSS գրելը: Հետագա ընթերցում
CSS @scope (MDN) «CSS @scope», Խուան Դիեգո Ռոդրիգես (CSS-Tricks) Firefox 146-ի թողարկման նշումներ (Firefox) Բրաուզերի աջակցություն (CanIUse) Հանրաճանաչ CSS Frameworks (CSS-ի վիճակը 2024) «C»-ն CSS-ում: Կասկադ», Թոմաս Յիպ (CSS-Tricks) BEM ներածություն (Ստացեք BEM)
