အခြေခံ CSS ၏ အခြေခံမူများကို လေ့လာသည့်အခါ၊ ထိန်းသိမ်းနိုင်မှုသေချာစေရန် Modular၊ ပြန်သုံးနိုင်သော၊ နှင့် ဖော်ပြမှုပုံစံများကို ရေးသားရန် သင်ကြားပေးပါသည်။ သို့သော် developer များသည် real-world applications များနှင့် ပတ်သက်လာသောအခါ၊ မရည်ရွယ်ထားသော နေရာများသို့ ပေါက်ကြားသွားသော စတိုင်များမပါဘဲ UI အင်္ဂါရပ်များကို ထည့်သွင်းရန် မဖြစ်နိုင်ကြောင်း ခံစားရလေ့ရှိသည်။ ဤပြဿနာသည် မိမိကိုယ်ကို ဖြည့်ဆည်းပေးသည့် ကွင်းထဲသို့ ဆီးနှင်းများ မကြာခဏ ပေါက်သွားတတ်သည်။ သီအိုရီအရ ဒြပ်စင်တစ်ခု သို့မဟုတ် အတန်းအစားတွင် ကန့်သတ်ထားသော စတိုင်များသည် ၎င်းတို့မသက်ဆိုင်သည့်နေရာတွင် စတင်ပြသသည်။ ၎င်းသည် ဆော့ဖ်ဝဲအင်ဂျင်နီယာအား ပေါက်ကြားနေသောပုံစံများကို အစားထိုးရန်၊ ထို့နောက်တွင် ဂလိုဘယ်စတိုင်များကို အမှတ်တမဲ့ အစားထိုးလိုက်ခြင်းစသည်ဖြင့် ပေါက်ကြားနေသော စတိုင်များကို အစားထိုးရန်အတွက် ဆော့ဖ်ဝဲအင်ဂျင်နီယာအား ပိုမိုတိကျသောရွေးချယ်မှုစနစ်များကို ဖန်တီးခိုင်းစေပါသည်။ BEM ကဲ့သို့သော တင်းကျပ်သော လူတန်းစားအမည် သဘောတူညီချက်များသည် ဤပြဿနာအတွက် သီအိုရီဆိုင်ရာ အဖြေတစ်ခုဖြစ်သည်။ BEM (Block၊ Element၊ Modifier) နည်းစနစ်သည် CSS ဖိုင်များအတွင်း ပြန်လည်အသုံးပြုနိုင်ရန်နှင့် ဖွဲ့စည်းတည်ဆောက်ပုံကို သေချာစေရန် CSS အတန်းများကို အမည်ပေးသည့်စနစ်တကျနည်းလမ်းဖြစ်သည်။ ဤကဲ့သို့သော ကွန်ဗင်းရှင်းများကို အမည်ပေးခြင်းသည် ဒြပ်စင်များနှင့် ၎င်းတို့၏အခြေအနေကို ဖော်ပြရန် ဒိုမိန်းဘာသာစကားကို အသုံးချခြင်းဖြင့် သိမြင်မှုဆိုင်ရာဝန်ထုပ်ဝန်ပိုးကို လျှော့ချနိုင်ပြီး မှန်ကန်စွာအကောင်အထည်ဖော်ပါက၊ ကြီးမားသောအပလီကေးရှင်းများအတွက် ပုံစံများကို ထိန်းသိမ်းရန် ပိုမိုလွယ်ကူစေနိုင်သည်။ သို့သော် လက်တွေ့လောကတွင်၊ အမြဲတမ်း ထိုကဲ့သို့ ဖြစ်မလာပါ။ ဦးစားပေးမှုများသည် ပြောင်းလဲနိုင်ပြီး အပြောင်းအလဲနှင့်အတူ အကောင်အထည်ဖော်မှုမှာ တသမတ်တည်းဖြစ်လာသည်။ HTML ဖွဲ့စည်းပုံသို့ သေးငယ်သော ပြောင်းလဲမှုများသည် CSS အတန်းအမည် ပြန်လည်ပြင်ဆင်မှုများ များစွာ လိုအပ်နိုင်သည်။ အလွန်အပြန်အလှန်အပြန်အလှန်အကျိုးသက်ရောက်မှုရှိသော ရှေ့တန်းအက်ပလီကေးရှင်းများနှင့်အတူ၊ BEM ပုံစံအတိုင်းလိုက်သော အတန်းအမည်များသည် ရှည်လျားပြီး ဟန်ချက်မညီဖြစ်လာနိုင်သည် (ဥပမာ၊ app-user-overview__status--is-authenticating) နှင့် အမည်ပေးခြင်းစည်းမျဥ်းများကို အပြည့်အဝလိုက်နာခြင်းမရှိပါက စနစ်၏ဖွဲ့စည်းပုံကို ချိုးဖောက်ကာ ၎င်း၏အကျိုးကျေးဇူးများကို ငြင်းပယ်နိုင်သည်။ ဤစိန်ခေါ်မှုများကြောင့် developer များသည် frameworks များဆီသို့ လှည့်လာကြသည်မှာ အံ့သြစရာမဟုတ်ပါ၊ Tailwind သည် လူကြိုက်အများဆုံး CSS framework ဖြစ်သည် ။ ပုံစံများကြားတွင် အနိုင်ယူ၍မရသော သီးခြားစစ်ပွဲတစ်ခုလို ပုံစံမျိုးကို တိုက်ခိုက်ရန် ကြိုးစားခြင်းထက်၊ CSS Cascade ကို စွန့်လွှတ်ရန်နှင့် ပြီးပြည့်စုံသော သီးခြားခွဲထားမှုကို အာမခံသည့် ကိရိယာများကို အသုံးပြုရန် လွယ်ကူသည်။ Developers များသည် Utilities များပေါ်တွင် ပိုမိုမှီခိုအားထားကြသည်။ အချို့သော developer များသည် cascaded ပုံစံများကို ရှောင်ရှားရန် စိတ်အားထက်သန်ကြောင်း ကျွန်ုပ်တို့ မည်သို့သိနိုင်သနည်း။ ၎င်းသည် CSS-in-JS မူဘောင်များကဲ့သို့ "ခေတ်မီသော" ရှေ့ဆုံးကိရိယာတန်ဆာပလာ၏ ထွန်းကားလာခြင်းဖြစ်သည် — ထိုရည်ရွယ်ချက်အတွက် အထူးထုတ်လုပ်ထားသည်။ သီးခြားအစိတ်အပိုင်းများအတွက် တင်းကျပ်စွာ ကန့်သတ်ထားသော သီးခြားပုံစံများဖြင့် လုပ်ဆောင်ခြင်းသည် လတ်ဆတ်သောလေကို ရှုရှိုက်ပုံရသည်။ ၎င်းသည် အရာများကို အမည်တပ်ရန် လိုအပ်သည်—အမုန်းဆုံးနှင့် အချိန်ကုန်သော ရှေ့ဆုံးအလုပ်များထဲမှ တစ်ခုဖြစ်နေသေးသည်—ကို ဖယ်ရှားပြီး CSS အမွေဆက်ခံခြင်း၏ အကျိုးကျေးဇူးများကို အပြည့်အဝနားလည်ခြင်း သို့မဟုတ် အသုံးချခြင်းမရှိဘဲ developer များ ဖြစ်ထွန်းလာစေရန် ခွင့်ပြုပေးပါသည်။ သို့သော် CSS Cascade ကို စွန့်ပစ်ခြင်းသည် ၎င်း၏ ပြဿနာများနှင့် လာပါသည်။ ဥပမာအားဖြင့်၊ JavaScript တွင် ပုံစံများကို ရေးဖွဲ့ခြင်းသည် လေးလံသော တည်ဆောက်မှုပုံစံများ လိုအပ်ပြီး အစိတ်အပိုင်း အမှတ်အသား သို့မဟုတ် HTML နှင့် မကြာခဏ ရောယှက်နေသော ပုံစံများကို မကြာခဏ ဖြစ်ပေါ်စေသည်။ အမည်ပေးခြင်းဆိုင်ရာ သဘောတူညီချက်များကို ဂရုတစိုက်ထည့်သွင်းစဉ်းစားမည့်အစား ကျွန်ုပ်တို့အတွက် ရွေးချယ်ပေးသူများနှင့် ခွဲခြားသတ်မှတ်မှုများကို အလိုအလျောက်ထုတ်ပေးရန် ဆော့ဖ်ဝဲများကို တည်ဆောက်ခွင့်ပြုသည် (ဥပမာ၊ .jsx-3130221066)၊ ဆော့ဖ်ဝဲအင်ဂျင်နီယာများသည် ၎င်းကိုယ်တိုင်နှင့် ၎င်းနှင့်အမှီလိုက်ရန် လိုအပ်ပါသည်။ (မင်းရဲ့ အစိတ်အပိုင်းရဲ့ အသုံးပြုမှု သက်ရောက်မှုအားလုံးကို နားလည်သဘောပေါက်မှု ဝန်ထုပ်ဝန်ပိုးက မလုံလောက်သေးဘူးလို့ ထင်သလိုပါပဲ။) အတန်းများကို ကိရိယာတန်ဆာပလာအဖြစ် အမည်ပေးခြင်း၏နောက်ထပ် အဓိပ္ပါယ်မှာ ဆော့ဖ်ဝဲရေးသားသူတူးလ်များကဲ့သို့ တိုက်ရိုက်အမှားရှာပြင်ခြင်းအား အသုံးချခြင်းထက် ဖွံ့ဖြိုးတိုးတက်မှုအတွက် စုစည်းထားသော သီးခြားအက်ပ်ဗားရှင်းများအတွက် အခြေခံအမှားရှာခြင်းကို မကြာခဏ ကန့်သတ်ထားသည်။ ဝဘ်က ပေးပြီးသားအရာတွေကို abstract လုပ်ဖို့ ကျွန်ုပ်တို့အသုံးပြုနေတဲ့ tools တွေကို debug လုပ်ဖို့ tools တွေ တီထွင်ဖို့ လိုသလောက်ပါပဲ — အားလုံးဟာ standard CSS ရေးခြင်းရဲ့ "နာကျင်မှု" နဲ့ဝေးရာကို ပြေးသွားဖို့အတွက်နဲ့ အားလုံးနီးပါးပါပဲ။ ကံကောင်းစွာဖြင့်၊ ခေတ်မီ CSS အင်္ဂါရပ်များသည် စံ CSS ရေးခြင်းကို ပို၍ လိုက်လျောညီထွေဖြစ်စေရုံသာမက ကျွန်ုပ်တို့ကဲ့သို့ developer များအား cascade ကို စီမံခန့်ခွဲရန်နှင့် ၎င်းကို ကျွန်ုပ်တို့အတွက် အလုပ်ဖြစ်စေရန် ပိုမိုစွမ်းဆောင်နိုင်စေပါသည်။ CSS Cascade Layers များသည် စံနမူနာကောင်းတစ်ခုဖြစ်သည်၊ သို့သော် အံ့သြစရာအာရုံများကင်းမဲ့သည့်နောက်ထပ်အင်္ဂါရပ်တစ်ခုရှိသည် — ၎င်းသည် မကြာသေးမီက Baseline သဟဇာတဖြစ်လာသည်နှင့် ယခုပြောင်းလဲနေပြီဖြစ်သည်။ CSS @scope At-Rule CSS @scope at-rule သည် ကျွန်ုပ်တို့ လွှမ်းခြုံထားသော စတိုင်-ယိုစိမ့်မှုဖြစ်စေသော စိုးရိမ်ပူပန်မှုမျိုးအတွက် ဖြစ်နိုင်ချေရှိသော ကုထုံးတစ်ခုဖြစ်သည်၊ ၎င်းသည် abstractions များနှင့် အပိုတည်ဆောက်ရေးကိရိယာများအတွက် မူရင်းဝဘ်အားသာချက်များကို အလျှော့မပေးဘဲ ကျွန်ုပ်တို့အား တွန်းအားပေးရန် တွန်းအားပေးခြင်းမရှိပါ။ "@scope CSS at-rule သည် သင့်အား သတ်သတ်မှတ်မှတ် DOM အခွဲအခွဲများရှိ ဒြပ်စင်များကို ရွေးချယ်နိုင်စေကာ၊ ဖျက်ရခက်သော အလွန်အကျွံ သတ်သတ်မှတ်မှတ်ရွေးချယ်ပေးသူများကို မရေးဘဲ တိတိပပနှင့် သင်၏ရွေးချယ်သူများကို DOM ဖွဲ့စည်းပုံနှင့် တင်းတင်းကြပ်ကြပ် ချိတ်ဆက်ခြင်းမပြုဘဲ အစိတ်အပိုင်းများကို ရွေးချယ်နိုင်စေပါသည်။"— MDN
တစ်နည်းဆိုရသော်၊ အမွေဆက်ခံမှု၊ ခွဲခြမ်းစိတ်ဖြာခြင်း သို့မဟုတ် စိုးရိမ်ပူပန်မှု၏ အခြေခံခွဲခြားမှုကိုပင် မပြုဘဲ သီးခြားဖြစ်ရပ်များတွင် ကျွန်ုပ်တို့ လုပ်ဆောင်နိုင်သည်၎င်းသည် ရှေ့ဆုံး ဖွံ့ဖြိုးတိုးတက်မှု၏ ရေရှည်လမ်းညွှန်မှုတစ်ခုဖြစ်သည်။ ထို့အပြင်၊ ၎င်းတွင်ကောင်းမွန်သော browser လွှမ်းခြုံမှုရှိသည်။ အမှန်မှာ၊ Firefox 146 သည် ဒီဇင်ဘာလတွင် @scope အတွက် ပံ့ပိုးမှုကို ပေါင်းထည့်ခဲ့ပြီး Baseline ကို ပထမဆုံးအကြိမ် သဟဇာတဖြစ်စေခဲ့သည်။ ဤသည်မှာ @scope စည်းမျဉ်းနှင့် BEM ပုံစံကို အသုံးပြုသည့် ခလုတ်တစ်ခုကြား ရိုးရှင်းသော နှိုင်းယှဉ်ချက်တစ်ခုဖြစ်သည်။
@scope စည်းမျဉ်းသည် ရှုပ်ထွေးမှုနည်းသော တိကျမှုကို ခွင့်ပြုသည်။ ဆော့ဖ်ဝဲအင်ဂျင်နီယာသည် အတန်းအမည်များကို အသုံးပြု၍ နယ်နိမိတ်များကို ဖန်တီးရန် မလိုအပ်တော့ဘဲ မူလ HTML ဒြပ်စင်များပေါ်တွင် အခြေခံ၍ ရွေးချယ်သူများကို ရေးနိုင်စေခြင်းဖြင့် CSS အတန်းအမည်ပုံစံများ လိုအပ်မှုကို ဖယ်ရှားပေးပါသည်။ အတန်းအမည်စီမံခန့်ခွဲမှုအတွက် လိုအပ်မှုကို ဖယ်ရှားလိုက်ရုံဖြင့်၊ @scope သည် ကြီးမားသော ပရောဂျက်များတွင် CSS နှင့် ဆက်စပ်နေသည့် အကြောက်တရားကို သက်သာစေနိုင်သည်။
အခြေခံအသုံးပြုမှု
စတင်ရန်၊ သင့် CSS တွင် @scope စည်းမျဉ်းကို ပေါင်းထည့်ကာ မည်သည့်စတိုင်များကို အတိုင်းအတာသတ်မှတ်မည်ကို အရင်းရွေးချယ်သည့်ကိရိယာကို ထည့်သွင်းပါ-
@scope (<ရွေးချယ်ရေး>) {
/*
ထို့ကြောင့် ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည်
@scope (nav) { { /* nav နယ်ပယ်အတွင်း လင့်ခ်ပုံစံများ */ }
a:active { /* Active link ပုံစံများ */ }
a:active::ရှေ့တွင် { /* အပိုစတိုင်ပုံစံအတွက် pseudo-ဒြပ်စင်ပါသော တက်ကြွသောလင့်ခ် */ }
@media (အများဆုံး-အကျယ်- 768px) { a { /* တုံ့ပြန်မှု ချိန်ညှိချက်များ */ } } }
၎င်းသည် ၎င်း၏ကိုယ်ပိုင်အားဖြင့်၊ အလွန်ထူးခြားသောအင်္ဂါရပ်မဟုတ်ပါ။ သို့သော်၊ နယ်ပယ်၏အစနှင့်အဆုံးအချက်များကို ထိထိရောက်ရောက်သတ်မှတ်ရန်၊ နိမ့်သောနယ်နိမိတ်ကိုဖန်တီးရန် နယ်ပယ်တွင် ဒုတိယအငြင်းအခုံကို ထည့်နိုင်သည်။
/* ul အတွင်းရှိ မည်သည့်ဒြပ်စင်မဆို စတိုင်များကို အသုံးပြုမည်မဟုတ်ပါ*/ @scope (nav) မှ (ul) { a { ဖောင့်အရွယ်အစား- 14px; } }
ဤအလေ့အကျင့်ကို ဒိုးနပ်စခုပ်ယူခြင်းဟုခေါ်သည်၊ ၎င်းသည် DOM ဖွဲ့စည်းတည်ဆောက်ပုံနှင့် တင်းတင်းကြပ်ကြပ်တွဲဖက်ထားသော အလားတူ၊ အလွန်တိကျသောရွေးချယ်မှုစီးရီးများ၊ :not pseudo-selector သို့မဟုတ် ကွဲပြားသော CSS ကိုကိုင်တွယ်ရန် ဒြပ်စင်များအတွင်း သီးခြားအတန်းအမည်များကို ဒြပ်စင်များအဖြစ် သတ်မှတ်ပေးခြင်းအပါအဝင် အသုံးပြုနိုင်သည့်နည်းလမ်းများစွာရှိပါသည်။ အခြားချဉ်းကပ်မှုများ မည်သို့ပင်ရှိစေကာမူ @scope method သည် ပိုမိုတိကျသည်။ ပို၍အရေးကြီးသည်မှာ၊ အတန်းအမည်များပြောင်းလဲပါက သို့မဟုတ် အလွဲသုံးစားလုပ်ပါက သို့မဟုတ် HTML ဖွဲ့စည်းပုံကို ပြုပြင်မည်ဆိုပါက ပျက်စီးနေသောပုံစံများအန္တရာယ်ကို ကာကွယ်ပေးပါသည်။ ယခု @scope သည် Baseline သဟဇာတဖြစ်သည့်အတွက် ကျွန်ုပ်တို့သည် ဖြေရှင်းနည်းများ မလိုအပ်တော့ပါ။ "စတိုင်ပုံရှစ်ပုံ" ကိုဖန်တီးရန် ဤအကြံဥာဏ်ကို အဆုံးဘောင်များစွာဖြင့် ထပ်မံရယူနိုင်သည်-
