Apabila mempelajari prinsip CSS asas, seseorang diajar untuk menulis gaya modular, boleh diguna semula dan deskriptif untuk memastikan kebolehselenggaraan. Tetapi apabila pembangun terlibat dengan aplikasi dunia sebenar, selalunya terasa mustahil untuk menambah ciri UI tanpa gaya bocor ke kawasan yang tidak diingini. Isu ini sering menjadi bola salji menjadi gelung pemenuhan diri; gaya yang secara teorinya merangkumi satu elemen atau kelas mula muncul di tempat yang tidak sesuai. Ini memaksa pembangun untuk mencipta pemilih yang lebih khusus untuk mengatasi gaya yang bocor, yang kemudiannya secara tidak sengaja menimpa gaya global, dan sebagainya. Konvensyen nama kelas tegar, seperti BEM, adalah satu penyelesaian teori untuk isu ini. Metodologi BEM (Block, Element, Modifier) ialah cara sistematik untuk menamakan kelas CSS untuk memastikan kebolehgunaan semula dan struktur dalam fail CSS. Penamaan konvensyen seperti ini boleh mengurangkan beban kognitif dengan memanfaatkan bahasa domain untuk menerangkan elemen dan keadaannya, dan jika dilaksanakan dengan betul, boleh menjadikan gaya untuk aplikasi besar lebih mudah dikekalkan. Di dunia nyata, bagaimanapun, ia tidak selalu berfungsi seperti itu. Keutamaan boleh berubah, dan dengan perubahan, pelaksanaan menjadi tidak konsisten. Perubahan kecil pada struktur HTML boleh memerlukan banyak semakan nama kelas CSS. Dengan aplikasi bahagian hadapan yang sangat interaktif, nama kelas yang mengikuti corak BEM boleh menjadi panjang dan sukar digunakan (mis., app-user-overview__status--is-authenticating), dan tidak mematuhi peraturan penamaan sepenuhnya memecahkan struktur sistem, dengan itu menafikan faedahnya. Memandangkan cabaran ini, tidak hairanlah pembangun telah beralih kepada rangka kerja, Tailwind menjadi rangka kerja CSS yang paling popular. Daripada cuba melawan apa yang kelihatan seperti perang kekhususan yang tidak boleh dimenangi antara gaya, lebih mudah untuk menyerah pada Cascade CSS dan menggunakan alat yang menjamin pengasingan lengkap. Pembangun Lebih Bersandar Pada Utiliti Bagaimanakah kita tahu bahawa sesetengah pembangun berminat untuk mengelakkan gaya berlatarkan? Ini adalah kebangkitan alat bahagian hadapan "moden" — seperti rangka kerja CSS-dalam-JS — direka khusus untuk tujuan itu. Bekerja dengan gaya terpencil yang berskop ketat kepada komponen tertentu boleh kelihatan seperti menghirup udara segar. Ia menghilangkan keperluan untuk menamakan sesuatu — masih merupakan salah satu tugas bahagian hadapan yang paling dibenci dan memakan masa — dan membolehkan pembangun menjadi produktif tanpa memahami sepenuhnya atau memanfaatkan faedah warisan CSS. Tetapi membuang CSS Cascade datang dengan masalahnya sendiri. Sebagai contoh, mengarang gaya dalam JavaScript memerlukan konfigurasi binaan yang berat dan selalunya membawa kepada gaya yang janggal bercampur dengan penanda komponen atau HTML. Daripada mempertimbangkan konvensyen penamaan dengan teliti, kami membenarkan alat binaan untuk menjana autogenerasi pemilih dan pengecam untuk kami (cth., .jsx-3130221066), yang memerlukan pembangun untuk mengikuti satu lagi bahasa pseudo dalam dirinya sendiri. (Seolah-olah beban kognitif untuk memahami perkara yang dilakukan oleh semua useEffects komponen anda belum mencukupi!) Mengabstraksi lebih lanjut tugas menamakan kelas kepada perkakas bermakna penyahpepijatan asas selalunya terhad kepada versi aplikasi tertentu yang disusun untuk pembangunan, dan bukannya memanfaatkan ciri penyemak imbas asli yang menyokong penyahpepijatan langsung, seperti Alat Pembangun. Ia hampir seperti kita perlu membangunkan alat untuk menyahpepijat alatan yang kita gunakan untuk mengabstrakkan perkara yang telah disediakan oleh web — semuanya demi melarikan diri daripada "sakit" menulis CSS standard. Nasib baik, ciri CSS moden bukan sahaja menjadikan penulisan CSS standard lebih fleksibel tetapi juga memberikan pembangun seperti kami kuasa yang lebih besar untuk mengurus lata dan menjadikannya berfungsi untuk kami. Lapisan Lata CSS ialah contoh yang bagus, tetapi terdapat satu lagi ciri yang mendapat kekurangan perhatian yang mengejutkan — walaupun ia berubah sekarang kerana ia baru-baru ini menjadi serasi Baseline. CSS @scope At-Rule Saya menganggap CSS @scope at-rule sebagai ubat yang berpotensi untuk jenis kebimbangan yang disebabkan oleh kebocoran gaya yang telah kami bincangkan, yang tidak memaksa kami untuk menjejaskan kelebihan web asli untuk abstraksi dan perkakas binaan tambahan. "Peraturan @scope CSS membolehkan anda memilih elemen dalam subpokok DOM tertentu, menyasarkan elemen dengan tepat tanpa menulis pemilih yang terlalu khusus yang sukar untuk ditindih dan tanpa menggabungkan pemilih anda terlalu ketat pada struktur DOM." - MDN
Dalam erti kata lain, kita boleh bekerja dengan gaya terpencil dalam keadaan tertentu tanpa mengorbankan warisan, melata atau pengasingan asas kebimbanganyang telah menjadi prinsip panduan jangka panjang pembangunan bahagian hadapan. Selain itu, ia mempunyai liputan penyemak imbas yang sangat baik. Malah, Firefox 146 menambah sokongan untuk @scope pada bulan Disember, menjadikannya Baseline serasi buat kali pertama. Berikut ialah perbandingan mudah antara butang menggunakan corak BEM berbanding peraturan @scope:
Peraturan @scope membenarkan ketepatan dengan kerumitan yang kurang. Pembangun tidak perlu lagi membuat sempadan menggunakan nama kelas, yang seterusnya membolehkan mereka menulis pemilih berdasarkan elemen HTML asli, dengan itu menghapuskan keperluan untuk corak nama kelas CSS preskriptif. Dengan hanya mengalih keluar keperluan untuk pengurusan nama kelas, @scope boleh mengurangkan ketakutan yang berkaitan dengan CSS dalam projek besar.
Penggunaan Asas
Untuk bermula, tambahkan peraturan @scope pada CSS anda dan masukkan pemilih akar kepada gaya yang akan diskop:
@skop (
Jadi, sebagai contoh, jika kita skop gaya kepada elemen
@skop (nav) { a { /* Gaya pautan dalam skop navigasi */ }
a:aktif { /* Gaya pautan aktif */ }
a:active::before { /* Pautan aktif dengan pseudo-element untuk penggayaan tambahan */ }
@media (lebar maksimum: 768px) { a { /* Pelarasan responsif */ } } }
Ini, dengan sendirinya, bukan ciri terobosan. Walau bagaimanapun, hujah kedua boleh ditambah pada skop untuk mencipta sempadan yang lebih rendah, dengan berkesan mentakrifkan titik mula dan tamat skop.
/* Mana-mana elemen di dalam ul tidak akan menggunakan gaya */ @skop (nav) hingga (ul) { a { saiz fon: 14px; } }
Amalan ini dipanggil skop donat, dan terdapat beberapa pendekatan yang boleh digunakan oleh seseorang, termasuk satu siri pemilih yang serupa dan sangat spesifik yang digandingkan rapat dengan struktur DOM, a :not pseudo-selector, atau memberikan nama kelas tertentu kepada elemen dalam
Kesimpulan Rangka kerja CSS yang mengutamakan utiliti, seperti Tailwind, berfungsi dengan baik untuk prototaip dan projek yang lebih kecil. Walau bagaimanapun, faedah mereka dengan cepat berkurangan apabila digunakan dalam projek yang lebih besar yang melibatkan lebih daripada beberapa pembangun. Pembangunan bahagian hadapan telah menjadi semakin rumit dalam beberapa tahun kebelakangan ini, dan CSS tidak terkecuali. Walaupun peraturan @skop bukanlah ubat untuk semua, ia boleh mengurangkan keperluan untuk perkakas yang kompleks. Apabila digunakan sebagai ganti, atau bersama penamaan kelas strategik, @scope boleh menjadikannya lebih mudah dan menyeronokkan untuk menulis CSS yang boleh diselenggara. Bacaan Selanjutnya
CSS @skop (MDN) “CSS @scope”, Juan Diego Rodríguez (CsS-Tricks) Nota Keluaran Firefox 146 (Firefox) Sokongan Penyemak Imbas (CanIUse) Rangka Kerja CSS Popular (Negeri CSS 2024) "C" dalam CSS: Cascade", Thomas Yip (CSS-Tricks) Pengenalan BEM (Dapatkan BEM)
