ເມື່ອຮຽນຮູ້ຫຼັກການພື້ນຖານຂອງ CSS, ຄົນ ໜຶ່ງ ໄດ້ຖືກສອນໃຫ້ຂຽນແບບໂມດູລາ, ສາມາດໃຊ້ຄືນໄດ້, ແລະອະທິບາຍເພື່ອຮັບປະກັນການຮັກສາໄວ້. ແຕ່ເມື່ອນັກພັດທະນາມີສ່ວນຮ່ວມກັບແອັບພລິເຄຊັນໃນໂລກທີ່ແທ້ຈິງ, ມັນມັກຈະຮູ້ສຶກວ່າເປັນໄປບໍ່ໄດ້ທີ່ຈະເພີ່ມຄຸນສົມບັດ UI ໂດຍບໍ່ມີຮູບແບບທີ່ຮົ່ວໄຫລເຂົ້າໄປໃນພື້ນທີ່ທີ່ບໍ່ໄດ້ຕັ້ງໃຈ. ບັນຫານີ້ມັກຈະ snowballs ເຂົ້າໄປໃນ loop ຕົນເອງສໍາເລັດ; ຮູບແບບທີ່ມີຂອບເຂດທາງທິດສະດີກັບອົງປະກອບຫນຶ່ງຫຼືຊັ້ນຮຽນເລີ່ມຕົ້ນສະແດງໃຫ້ເຫັນບ່ອນທີ່ພວກເຂົາບໍ່ໄດ້ເປັນ. ອັນນີ້ບັງຄັບໃຫ້ຜູ້ພັດທະນາສ້າງຕົວເລືອກສະເພາະຫຼາຍຂື້ນເພື່ອລົບລ້າງຮູບແບບທີ່ຮົ່ວໄຫຼ, ເຊິ່ງຫຼັງຈາກນັ້ນມັນບັງເອີນ override ຮູບແບບທົ່ວໂລກ, ແລະອື່ນໆ. ສົນທິສັນຍາຊື່ຊັ້ນແຂງ, ເຊັ່ນ: BEM, ແມ່ນທາງທິດສະດີອັນໜຶ່ງຕໍ່ກັບບັນຫານີ້. ວິທີການ BEM (Block, Element, Modifier) ເປັນວິທີການຕັ້ງຊື່ຫ້ອງຮຽນ CSS ທີ່ເປັນລະບົບເພື່ອຮັບປະກັນການນໍາມາໃຊ້ຄືນໃຫມ່ແລະໂຄງສ້າງພາຍໃນໄຟລ໌ CSS. ການຕັ້ງຊື່ສົນທິສັນຍາດັ່ງກ່າວສາມາດຫຼຸດຜ່ອນການໂຫຼດມັນສະຫມອງໂດຍການໃຊ້ພາສາໂດເມນເພື່ອອະທິບາຍອົງປະກອບແລະສະຖານະຂອງມັນ, ແລະຖ້າຖືກປະຕິບັດຢ່າງຖືກຕ້ອງ, ສາມາດເຮັດໃຫ້ຮູບແບບສໍາລັບຄໍາຮ້ອງສະຫມັກຂະຫນາດໃຫຍ່ງ່າຍຕໍ່ການຮັກສາ. ໃນໂລກທີ່ແທ້ຈິງ, ແນວໃດກໍ່ຕາມ, ມັນບໍ່ໄດ້ເປັນແບບນັ້ນສະເຫມີໄປ. ບູລິມະສິດສາມາດປ່ຽນແປງໄດ້, ແລະດ້ວຍການປ່ຽນແປງ, ການປະຕິບັດຈະກາຍເປັນຄວາມບໍ່ສອດຄ່ອງ. ການປ່ຽນແປງຂະຫນາດນ້ອຍຂອງໂຄງສ້າງ HTML ສາມາດຮຽກຮ້ອງໃຫ້ມີການແກ້ໄຂຊື່ຊັ້ນ CSS ຫຼາຍ. ດ້ວຍຄໍາຮ້ອງສະຫມັກດ້ານຫນ້າທີ່ມີການໂຕ້ຕອບສູງ, ຊື່ຫ້ອງຮຽນຕາມຮູບແບບ BEM ສາມາດກາຍເປັນຍາວແລະບໍ່ສະບາຍ (ເຊັ່ນ: app-user-overview__status--is-autheticating), ແລະການບໍ່ປະຕິບັດຕາມກົດລະບຽບການຕັ້ງຊື່ຢ່າງສົມບູນທໍາລາຍໂຄງສ້າງຂອງລະບົບ, ດັ່ງນັ້ນການປະຕິເສດຜົນປະໂຫຍດຂອງມັນ. ເນື່ອງຈາກສິ່ງທ້າທາຍເຫຼົ່ານີ້, ມັນບໍ່ແປກໃຈທີ່ນັກພັດທະນາໄດ້ຫັນໄປສູ່ກອບ, Tailwind ເປັນກອບ CSS ທີ່ນິຍົມທີ່ສຸດ. ແທນທີ່ຈະພະຍາຍາມຕໍ່ສູ້ກັບສິ່ງທີ່ເບິ່ງຄືວ່າເປັນສົງຄາມສະເພາະທີ່ບໍ່ສາມາດຊະນະລະຫວ່າງຮູບແບບຕ່າງໆ, ມັນງ່າຍທີ່ຈະຍອມແພ້ CSS Cascade ແລະໃຊ້ເຄື່ອງມືທີ່ຮັບປະກັນການໂດດດ່ຽວຢ່າງສົມບູນ. ນັກພັດທະນາເອື່ອຍອີງເພີ່ມເຕີມກ່ຽວກັບ Utilities ພວກເຮົາຈະຮູ້ໄດ້ແນວໃດວ່ານັກພັດທະນາບາງຄົນກະຕືລືລົ້ນທີ່ຈະຫຼີກເວັ້ນຮູບແບບ cascaded? ມັນແມ່ນການເພີ່ມຂື້ນຂອງເຄື່ອງມືດ້ານຫນ້າ "ທີ່ທັນສະໄຫມ" - ເຊັ່ນ CSS-in-JS frameworks - ຖືກອອກແບບໂດຍສະເພາະສໍາລັບຈຸດປະສົງນັ້ນ. ການເຮັດວຽກກັບຮູບແບບທີ່ໂດດດ່ຽວທີ່ມີຂອບເຂດທີ່ເຄັ່ງຄັດກັບອົງປະກອບສະເພາະສາມາດເບິ່ງຄືວ່າເປັນລົມຫາຍໃຈຂອງອາກາດສົດ. ມັນກໍາຈັດຄວາມຕ້ອງການທີ່ຈະຕັ້ງຊື່ສິ່ງຕ່າງໆ - ຍັງເປັນຫນຶ່ງໃນຫນ້າກຽດຊັງທີ່ສຸດແລະໃຊ້ເວລາຫຼາຍ - ແລະອະນຸຍາດໃຫ້ນັກພັດທະນາສາມາດຜະລິດໄດ້ໂດຍບໍ່ມີການເຂົ້າໃຈຢ່າງເຕັມສ່ວນຫຼືນໍາໃຊ້ຜົນປະໂຫຍດຂອງມໍລະດົກ CSS. ແຕ່ການຍົກເລີກ CSS Cascade ມາພ້ອມກັບບັນຫາຂອງຕົນເອງ. ຕົວຢ່າງເຊັ່ນ, ການປະກອບຮູບແບບໃນ JavaScript ຮຽກຮ້ອງໃຫ້ມີການຕັ້ງຄ່າທີ່ຫນັກແຫນ້ນແລະມັກຈະເຮັດໃຫ້ຮູບແບບທີ່ສັບສົນກັບເຄື່ອງຫມາຍອົງປະກອບຫຼື HTML. ແທນທີ່ຈະພິຈາລະນາຢ່າງລະມັດລະວັງການຕັ້ງຊື່, ພວກເຮົາອະນຸຍາດໃຫ້ສ້າງເຄື່ອງມືເພື່ອຜະລິດຕົວເລືອກແລະຕົວລະບຸອັດຕະໂນມັດສໍາລັບພວກເຮົາ (ເຊັ່ນ: .jsx-3130221066), ຮຽກຮ້ອງໃຫ້ຜູ້ພັດທະນາຕິດຕາມພາສາ pseudo ອື່ນໃນຕົວຂອງມັນເອງ. (ເຊັ່ນກັບວ່າການໂຫຼດມັນສະຫມອງຂອງການເຂົ້າໃຈສິ່ງທີ່ຜົນກະທົບການນໍາໃຊ້ອົງປະກອບທັງຫມົດຂອງທ່ານເຮັດແມ່ນບໍ່ພຽງພໍ!) ການເຮັດວຽກທີ່ບໍ່ມີຕົວຕົນເພີ່ມເຕີມຂອງການຕັ້ງຊື່ຫ້ອງຮຽນກັບເຄື່ອງມືຫມາຍຄວາມວ່າການດີບັກພື້ນຖານມັກຈະຖືກຈໍາກັດກັບສະບັບຄໍາຮ້ອງສະຫມັກສະເພາະທີ່ລວບລວມສໍາລັບການພັດທະນາ, ແທນທີ່ຈະໃຊ້ຄຸນສົມບັດຂອງຕົວທ່ອງເວັບພື້ນເມືອງທີ່ສະຫນັບສະຫນູນການດີບັກສົດ, ເຊັ່ນ: ເຄື່ອງມືນັກພັດທະນາ. ມັນເກືອບຄືກັບວ່າພວກເຮົາຕ້ອງພັດທະນາເຄື່ອງມືເພື່ອແກ້ບັນຫາເຄື່ອງມືທີ່ພວກເຮົາກໍາລັງໃຊ້ເພື່ອ abstract ສິ່ງທີ່ເວັບສະຫນອງໃຫ້ - ທັງຫມົດເພື່ອປະໂຫຍດຂອງການແລ່ນຫນີຈາກ "ຄວາມເຈັບປວດ" ຂອງການຂຽນມາດຕະຖານ CSS. ໂຊກດີ, ຄຸນສົມບັດ CSS ທີ່ທັນສະໄຫມບໍ່ພຽງແຕ່ເຮັດໃຫ້ການຂຽນມາດຕະຖານ CSS ມີຄວາມຍືດຫຍຸ່ນຫຼາຍ, ແຕ່ຍັງໃຫ້ນັກພັດທະນາເຊັ່ນພວກເຮົາມີອໍານາດຫຼາຍໃນການຄຸ້ມຄອງ cascade ແລະເຮັດໃຫ້ມັນເຮັດວຽກສໍາລັບພວກເຮົາ. CSS Cascade Layers ເປັນຕົວຢ່າງທີ່ດີ, ແຕ່ມີຄຸນສົມບັດອື່ນທີ່ຂາດຄວາມສົນໃຈ - ເຖິງແມ່ນວ່າມັນມີການປ່ຽນແປງໃນປັດຈຸບັນທີ່ມັນໄດ້ກາຍເປັນພື້ນຖານທີ່ເຫມາະສົມ. CSS @scope At-Rule ຂ້ອຍຖືວ່າ CSS @scope at-rule ເປັນການປິ່ນປົວທີ່ມີທ່າແຮງສໍາລັບການຈັດລຽງຂອງຄວາມວຸ້ນວາຍແບບຮົ່ວໄຫຼທີ່ພວກເຮົາໄດ້ກວມເອົາ, ອັນທີ່ບໍ່ໄດ້ບັງຄັບໃຫ້ພວກເຮົາປະນີປະນອມຂໍ້ດີເວັບພື້ນເມືອງສໍາລັບການບໍ່ມີຕົວຕົນແລະເຄື່ອງມືເສີມສ້າງ. "ກົດລະບຽບ @scope CSS ຊ່ວຍໃຫ້ທ່ານສາມາດເລືອກອົງປະກອບໃນຕົ້ນໄມ້ຍ່ອຍ DOM ສະເພາະ, ກໍານົດເປົ້າຫມາຍອົງປະກອບຢ່າງແນ່ນອນໂດຍບໍ່ຕ້ອງຂຽນຕົວເລືອກສະເພາະຫຼາຍເກີນໄປທີ່ຍາກທີ່ຈະ override, ແລະບໍ່ເຊື່ອມຕໍ່ຕົວເລືອກຂອງທ່ານແຫນ້ນເກີນໄປກັບໂຄງສ້າງ DOM."— MDN
ເວົ້າອີກຢ່າງ ໜຶ່ງ, ພວກເຮົາສາມາດເຮັດວຽກກັບຮູບແບບທີ່ໂດດດ່ຽວໃນກໍລະນີສະເພາະໂດຍບໍ່ມີການເສຍສະລະການສືບທອດ, ການຕົກເປັນເຫຍື່ອ, ຫຼືແມ້ກະທັ້ງການແບ່ງແຍກພື້ນຖານຂອງຄວາມກັງວົນ.ນັ້ນແມ່ນຫຼັກການຊີ້ນຳອັນຍາວນານຂອງການພັດທະນາດ້ານໜ້າ. ນອກຈາກນັ້ນ, ມັນມີການຄຸ້ມຄອງຕົວທ່ອງເວັບທີ່ດີເລີດ. ໃນຄວາມເປັນຈິງ, Firefox 146 ເພີ່ມການສະຫນັບສະຫນູນ @scope ໃນເດືອນທັນວາ, ເຮັດໃຫ້ມັນເຂົ້າກັນໄດ້ Baseline ເປັນຄັ້ງທໍາອິດ. ນີ້ແມ່ນການປຽບທຽບງ່າຍໆລະຫວ່າງປຸ່ມທີ່ໃຊ້ຮູບແບບ BEM ທຽບກັບກົດລະບຽບ @scope:
ກົດລະບຽບ @scope ອະນຸຍາດໃຫ້ມີຄວາມຊັດເຈນກັບຄວາມສັບສົນຫນ້ອຍ. ນັກພັດທະນາບໍ່ຈໍາເປັນຕ້ອງສ້າງຂອບເຂດໂດຍໃຊ້ຊື່ຊັ້ນ, ເຊິ່ງ, ໃນທາງກັບກັນ, ອະນຸຍາດໃຫ້ພວກເຂົາຂຽນຕົວເລືອກໂດຍອີງໃສ່ອົງປະກອບ HTML ພື້ນເມືອງ, ດັ່ງນັ້ນການກໍາຈັດຄວາມຕ້ອງການສໍາລັບຮູບແບບຊື່ຊັ້ນ CSS ຕາມໃບສັ່ງ. ໂດຍພຽງແຕ່ເອົາຄວາມຕ້ອງການການຄຸ້ມຄອງຊື່ຊັ້ນ, @scope ສາມາດບັນເທົາຄວາມຢ້ານກົວທີ່ກ່ຽວຂ້ອງກັບ CSS ໃນໂຄງການຂະຫນາດໃຫຍ່.
ການນໍາໃຊ້ພື້ນຖານ
ເພື່ອເລີ່ມຕົ້ນ, ເພີ່ມກົດລະບຽບ @scope ໃສ່ CSS ຂອງທ່ານແລະໃສ່ຕົວເລືອກຮາກເພື່ອກໍານົດຂອບເຂດຮູບແບບ:
@scope (<ເລືອກ>) {
/* ຮູບແບບທີ່ກຳນົດໄວ້ໃນ
ດັ່ງນັ້ນ, ສໍາລັບຕົວຢ່າງ, ຖ້າພວກເຮົາກໍານົດຂອບເຂດຮູບແບບໃຫ້ກັບອົງປະກອບ
@ຂອບເຂດ (nav) { a { /* ຮູບແບບການເຊື່ອມໂຍງພາຍໃນຂອບເຂດ nav */ }
a:active { /* ຮູບແບບການເຊື່ອມໂຍງທີ່ໃຊ້ງານ */ }
a:active::before { /* Active link with pseudo-element for extra styling */ }
@media (ຄວາມກວ້າງສູງສຸດ: 768px) { a { /* ການປັບຕົວແບບຕອບສະໜອງ */ } } }
ນີ້, ດ້ວຍຕົວມັນເອງ, ບໍ່ແມ່ນຄຸນສົມບັດທີ່ໂດດເດັ່ນ. ຢ່າງໃດກໍ່ຕາມ, ການໂຕ້ຖຽງທີສອງສາມາດຖືກເພີ່ມເຂົ້າໃນຂອບເຂດເພື່ອສ້າງຂອບເຂດຕ່ໍາ, ການກໍານົດຂອບເຂດຂອງຂອບເຂດແລະຈຸດສິ້ນສຸດຢ່າງມີປະສິດທິຜົນ.
/* ອົງປະກອບໃດຫນຶ່ງຢູ່ໃນ ul ຈະບໍ່ມີການນໍາໃຊ້ຮູບແບບ */ @scope (nav) ເຖິງ (ul) { ເປັນ { font-size: 14px; } }
ການປະຕິບັດນີ້ເອີ້ນວ່າ donut scope, ແລະມີຫຼາຍວິທີການທີ່ຫນຶ່ງສາມາດນໍາໃຊ້, ລວມທັງຊຸດຂອງຕົວເລືອກທີ່ຄ້າຍຄືກັນ, ສະເພາະສູງທີ່ປະສົມປະສານຢ່າງແຫນ້ນຫນາກັບໂຄງສ້າງ DOM, a :not pseudo-selector, ຫຼືການກໍານົດຊື່ຫ້ອງຮຽນສະເພາະກັບ ອົງປະກອບພາຍໃນ
ສະຫຼຸບ Utility-first frameworks CSS, ເຊັ່ນ Tailwind, ເຮັດວຽກໄດ້ດີສໍາລັບການສ້າງຕົວແບບ ແລະໂຄງການຂະຫນາດນ້ອຍກວ່າ. ຜົນປະໂຫຍດຂອງພວກມັນຫຼຸດລົງຢ່າງໄວວາ, ແນວໃດກໍ່ຕາມ, ເມື່ອໃຊ້ໃນໂຄງການຂະຫນາດໃຫຍ່ທີ່ກ່ຽວຂ້ອງກັບນັກພັດທະນາຫຼາຍກວ່າຄູ່. ການພັດທະນາດ້ານຫນ້າໄດ້ກາຍເປັນຄວາມສັບສົນຫຼາຍຂື້ນໃນສອງສາມປີຜ່ານມາ, ແລະ CSS ແມ່ນບໍ່ມີຂໍ້ຍົກເວັ້ນ. ໃນຂະນະທີ່ກົດລະບຽບ @scope ບໍ່ແມ່ນການປິ່ນປົວທັງຫມົດ, ມັນສາມາດຫຼຸດຜ່ອນຄວາມຕ້ອງການເຄື່ອງມືທີ່ສັບສົນ. ເມື່ອໃຊ້ແທນ, ຫຼືຄຽງຄູ່ກັບການຕັ້ງຊື່ຫ້ອງຮຽນຍຸດທະສາດ, @scope ສາມາດເຮັດໃຫ້ການຂຽນ CSS ຮັກສາໄດ້ງ່າຍຂຶ້ນ ແລະມ່ວນກວ່າ. ອ່ານເພີ່ມເຕີມ
CSS @scope (MDN) “CSS @scope”, Juan Diego Rodríguez (CSS-Tricks) ບັນທຶກການປ່ອຍ Firefox 146 (Firefox) ຮອງຮັບຕົວທ່ອງເວັບ (CanIUuse) CSS Frameworks ຍອດນິຍົມ (ສະຖານະຂອງ CSS 2024) "C" ໃນ CSS: Cascade", Thomas Yip (CSS-Tricks) ການແນະນຳ BEM (ຮັບ BEM)
