Үндсэн CSS-ийн зарчмуудыг сурахдаа тогтвортой байдлыг хангах үүднээс модульчлагдсан, дахин ашиглах боломжтой, дүрсэлсэн хэв маягийг бичихийг заадаг. Гэвч хөгжүүлэгчид бодит ертөнцийн программуудтай холбогдож эхлэхэд загвар нь төлөвлөгдөөгүй газар руу урсахгүйгээр UI функцуудыг нэмэх боломжгүй мэт санагддаг. Энэ асуудал нь ихэвчлэн өөрөө биелэх гогцоо руу цасан бөмбөг; Онолын хувьд нэг элемент эсвэл ангид хамаарах хэв маяг нь хамаарахгүй газар гарч эхэлдэг. Энэ нь хөгжүүлэгчийг задруулсан хэв маягийг хүчингүй болгохын тулд илүү тодорхой сонгогчийг бий болгоход хүргэдэг бөгөөд энэ нь глобал хэв маягийг санамсаргүйгээр дарах гэх мэт. BEM гэх мэт хатуу ангиллын нэрсийн конвенцууд нь энэ асуудлын онолын нэг шийдэл юм. BEM (Блок, Элемент, Өөрчлөгч) аргачлал нь CSS файлуудын дотор дахин ашиглах, бүтцийг баталгаажуулахын тулд CSS ангиудыг нэрлэх системчилсэн арга юм. Энэ мэтээр нэрлэсэн конвенцуудыг нэрлэх нь домэйн хэлийг ашиглан элементүүд болон тэдгээрийн төлөвийг тайлбарлах замаар танин мэдэхүйн ачааллыг бууруулж, зөв хэрэгжүүлбэл том программуудын хэв маягийг засварлахад хялбар болгож чадна. Гэсэн хэдий ч бодит ертөнцөд энэ нь үргэлж тийм байдаггүй. Тэргүүлэх чиглэлүүд өөрчлөгдөж болох ба өөрчлөлтийг дагаад хэрэгжилт нь нийцэхгүй болдог. HTML бүтцэд бага зэрэг өөрчлөлт оруулахад CSS ангиллын нэрийг олон удаа засварлах шаардлагатай болдог. Өндөр интерактив хэрэглээний программуудын хувьд BEM загварыг дагаж байгаа ангийн нэрс нь урт бөгөөд төвөгтэй болж (жишээ нь, програм-хэрэглэгчийн ерөнхий тойм__төлөв - баталгаажуулж байна) бөгөөд нэрлэх дүрмийг бүрэн дагаж мөрдөхгүй байх нь системийн бүтцийг эвдэж, улмаар түүний ашиг тусыг үгүйсгэдэг. Эдгээр сорилтуудыг харгалзан хөгжүүлэгчид фреймворк руу хандсан нь гайхах зүйл биш бөгөөд Tailwind нь хамгийн алдартай CSS хүрээ юм. Загваруудын хооронд үл ялагдашгүй өвөрмөц байдлын дайнтай тэмцэхийн оронд CSS Cascade-аас татгалзаж, бүрэн тусгаарлалтыг баталгаажуулах хэрэгслийг ашиглах нь илүү хялбар байдаг. Хөгжүүлэгчид хэрэгслүүдэд илүү найддаг Зарим хөгжүүлэгчид каскадын хэв маягаас зайлсхийх сонирхолтой байгааг бид яаж мэдэх вэ? Энэ нь тусгайлан зориулж бүтээсэн CSS-in-JS хүрээ гэх мэт "орчин үеийн" урд талын хэрэгслүүдийн өсөлт юм. Тодорхой бүрэлдэхүүн хэсгүүдтэй нягт уялдаатай тусгаарлагдсан хэв маягтай ажиллах нь цэвэр агаар мэт санагдаж магадгүй юм. Энэ нь хамгийн үзэн яддаг, цаг хугацаа шаардсан даалгавруудын нэг хэвээр байгаа зүйлсийг нэрлэх хэрэгцээг арилгаж, хөгжүүлэгчдэд CSS-ийн өв залгамжлалын давуу талыг бүрэн ойлгох, ашиглахгүйгээр бүтээмжтэй ажиллах боломжийг олгодог. Гэхдээ CSS Cascade-аас татгалзах нь өөрийн гэсэн асуудалтай байдаг. Жишээлбэл, JavaScript-д хэв маяг зохиох нь хүнд хэлбэрийн тохиргоо шаарддаг бөгөөд энэ нь ихэвчлэн бүрэлдэхүүн хэсгийн тэмдэглэгээ эсвэл HTML-тэй эвгүй холилдоход хүргэдэг. Нэршүүлэх конвенцуудыг сайтар бодож үзэхийн оронд бид сонгох хэрэгсэл болон танигчийг автоматаар үүсгэх (жишээ нь, .jsx-3130221066) хэрэгслийг бүтээх боломжийг олгодог бөгөөд хөгжүүлэгчдийг өөр нэг псевдо хэлийг дагаж мөрдөхийг шаарддаг. (Таны бүх бүрэлдэхүүн хэсгийн useEffects юу хийдэгийг ойлгох танин мэдэхүйн ачаалал хангалттай биш байсан юм шиг!) Ангиудыг багаж хэрэгсэл болгон нэрлэх ажлыг цаашид хийсвэрлэх нь үндсэн дибаг хийх нь Хөгжүүлэгчийн хэрэгсэл гэх мэт шууд дибаг хийхийг дэмждэг төрөлх хөтчийн функцуудыг ашиглахаас илүүтэйгээр хөгжүүлэлтэд зориулж эмхэтгэсэн програмын тодорхой хувилбаруудад хязгаарлагддаг гэсэн үг юм. Стандарт CSS бичих "зовлон"-оос зугтахын тулд вэбээр хангадаг зүйлсийг хийсвэрлэхийн тулд хэрэглэж буй хэрэгслүүдээ дибаг хийх хэрэгслүүдийг боловсруулах хэрэгтэй юм шиг байна. Аз болоход, орчин үеийн CSS функцууд нь стандарт CSS бичихийг илүү уян хатан болгоод зогсохгүй бидэн шиг хөгжүүлэгчдэд каскадыг удирдаж, үүнийг бидэнд ашиглахад илүү их хүчийг өгдөг. CSS Cascade Layers бол гайхалтай жишээ боловч анхаарал татахуйц өөр нэг онцлог шинж чанар байдаг - гэхдээ энэ нь саяхан үндсэн түвшинд нийцтэй болсон тул одоо өөрчлөгдөж байна. CSS @scope At-Rule Би CSS @scope at-rule нь бидний авч үзсэн хэв маягийн алдагдлаас үүдэлтэй түгшүүрийг арилгах боломжит эмчилгээ гэж би үзэж байгаа бөгөөд энэ нь хийсвэрлэл болон нэмэлт бүтээх хэрэгслийн үндсэн вэб давуу талыг алдагдуулахад хүргэдэггүй. "@scope CSS-ийн дүрэм нь танд DOM-ийн дэд моднуудын элементүүдийг сонгох боломжийг олгодог бөгөөд үүнийг дарахад хэцүү хэт тусгай сонгогчийг бичихгүйгээр, мөн өөрийн сонгогчдыг DOM бүтцэд хэт нягт холбохгүйгээр чиглүүлж болно."- MDN.
Өөрөөр хэлбэл, бид өв залгамжлал, шат дамжлага, тэр ч байтугай санаа зовоосон асуудлын үндсэн тусгаарлалтыг алдагдуулахгүйгээр тодорхой тохиолдлуудад тусгаарлагдсан хэв маягтай ажиллах боломжтой.Энэ нь урд талын хөгжлийн урт хугацааны үндсэн зарчим байсаар ирсэн. Нэмж дурдахад энэ нь хөтөчийн хамрах хүрээг маш сайн хангадаг. Үнэн хэрэгтээ Firefox 146 нь арванхоёрдугаар сард @scope-ийн дэмжлэгийг нэмсэн нь анх удаа Baseline-д нийцтэй болсон. BEM загварыг ашигладаг товчлуурыг @ хамрах хүрээний дүрмийн хооронд энгийн харьцуулалт энд байна:
<загвар> .button .button__text { /* товчлуурын текстийн хэв маяг */ } .button .button__icon { /* товчлуурын дүрсний загвар */ } .button--анхдагч { үндсэн товчлуурын загварууд */ }
<загвар> @хамрах хүрээ (.үндсэн товчлуур) { span:first-child { /* товчлуурын текстийн хэв маяг */ } span: last-child { /* товчлуурын дүрсний загвар */ } }
@Scope дүрэм нь нарийн төвөгтэй байдал багатай нарийвчлалтай байхыг зөвшөөрдөг. Хөгжүүлэгч нь ангийн нэрийг ашиглан хил хязгаар үүсгэх шаардлагагүй болсон бөгөөд энэ нь эргээд эх HTML элементүүд дээр тулгуурлан сонгогч бичих боломжийг олгодог бөгөөд ингэснээр CSS ангиллын нэрийн загварчлалын хэрэгцээг арилгадаг. Ангийн нэрийн менежментийн хэрэгцээг зүгээр л арилгаснаар @scope том төслүүдэд CSS-тэй холбоотой айдсыг бууруулж чадна. Үндсэн хэрэглээ Эхлэхийн тулд CSS-дээ @scope дүрмийг нэмж, загваруудын хамрах хүрээг сонгох үндэс сонгогчийг оруулна уу: @хамрах хүрээ (<сонгогч>) { /* Загваруудыг <сонгогч>-д оруулсан */ }
Жишээлбэл, хэрэв бид
@хамрах хүрээ (нав) { a { /* навигацийн хүрээн дэх холбоосын загварууд */ }
a:active { /* Идэвхтэй холбоосын загварууд */ }
a:active::prefor { /* Нэмэлт загварт зориулсан псевдо элемент бүхий идэвхтэй холбоос */ }
@media (хамгийн их өргөн: 768px) { a { /* Хариуцлагатай тохируулга */ } } }
Энэ нь дангаараа шинэлэг шинж чанар биш юм. Гэсэн хэдий ч хамрах хүрээний эхлэл ба төгсгөлийн цэгийг үр дүнтэй тодорхойлж, доод хилийг бий болгохын тулд хоёр дахь аргументыг хамрах хүрээнд нэмж болно.
/* ul доторх ямар ч элементэд хэв маяг хэрэглэхгүй */ @scope (nav) хүртэл (ul) { а { үсгийн хэмжээ: 14px; } }
Энэ практикийг Donut scoping гэж нэрлэдэг бөгөөд DOM бүтцэд нягт холбогдсон ижил төстэй, өндөр өвөрмөц сонгогч, :not pseudo-selector, эсвэл өөр өөр CSS-ийг зохицуулахын тулд
/*
Дүгнэлт Tailwind гэх мэт хэрэглүүрийн анхны CSS хүрээ нь прототип болон жижиг төслүүдэд сайн ажилладаг. Гэсэн хэдий ч хэд хэдэн хөгжүүлэгч оролцсон томоохон төслүүдэд ашиглах үед тэдний ашиг тус хурдан буурдаг. Сүүлийн хэдэн жилд урд талын хөгжүүлэлт улам бүр төвөгтэй болж байгаа бөгөөд CSS нь үл хамаарах зүйл биш юм. @ хамрах хүрээний дүрэм нь бүх зүйлийг эмчлэх боломжгүй боловч нарийн төвөгтэй багаж хэрэгслийн хэрэгцээг багасгаж чадна. Стратегийн ангийн нэршлийн оронд эсвэл хажууд нь ашиглах үед @scope нь засвар үйлчилгээ хийх боломжтой CSS бичихэд илүү хялбар бөгөөд хөгжилтэй болгодог. Цааш унших
CSS @хамрах хүрээ (MDN) “CSS @scope”, Хуан Диего Родригес (CSS-Tricks) Firefox 146 хувилбарын тэмдэглэл (Firefox) Хөтөчийн дэмжлэг (CanIUse) Алдартай CSS Frameworks (CSS 2024 төлөв) "CSS дэх "С": Каскад", Томас Ип (CSS-Tricks) BEM-ийн танилцуулга (BEM авах)
