Saat mempelajari prinsip dasar CSS, seseorang diajarkan untuk menulis gaya modular, dapat digunakan kembali, dan deskriptif untuk memastikan pemeliharaan. Namun ketika pengembang terlibat dengan aplikasi dunia nyata, seringkali terasa mustahil untuk menambahkan fitur UI tanpa gaya bocor ke area yang tidak diinginkan. Masalah ini sering kali berkembang menjadi lingkaran yang terwujud dengan sendirinya; gaya yang secara teori tercakup dalam satu elemen atau kelas mulai muncul di tempat yang bukan tempatnya. Hal ini memaksa pengembang untuk membuat penyeleksi yang lebih spesifik untuk mengganti gaya yang bocor, yang kemudian secara tidak sengaja menimpa gaya global, dan seterusnya. Konvensi nama kelas yang kaku, seperti BEM, adalah salah satu solusi teoritis untuk masalah ini. Metodologi BEM (Block, Element, Modifier) adalah cara sistematis dalam memberi nama kelas CSS untuk memastikan penggunaan kembali dan struktur dalam file CSS. Konvensi penamaan seperti ini dapat mengurangi beban kognitif dengan memanfaatkan bahasa domain untuk mendeskripsikan elemen dan statusnya, dan jika diterapkan dengan benar, dapat membuat gaya untuk aplikasi besar lebih mudah dipertahankan. Namun di dunia nyata, hal tersebut tidak selalu berjalan seperti itu. Prioritas dapat berubah, dan seiring dengan perubahan, implementasi menjadi tidak konsisten. Perubahan kecil pada struktur HTML memerlukan banyak revisi nama kelas CSS. Dengan aplikasi front-end yang sangat interaktif, nama kelas yang mengikuti pola BEM bisa menjadi panjang dan sulit digunakan (misalnya, app-user-overview__status--is-authenticating), dan tidak sepenuhnya mengikuti aturan penamaan akan merusak struktur sistem, sehingga meniadakan manfaatnya. Mengingat tantangan ini, tidak mengherankan jika pengembang beralih ke kerangka kerja, Tailwind menjadi kerangka kerja CSS paling populer. Daripada mencoba melawan apa yang tampak seperti perang kekhususan antar gaya yang tidak dapat dimenangkan, lebih mudah untuk menyerah pada CSS Cascade dan menggunakan alat yang menjamin isolasi total. Pengembang Lebih Bersandar Pada Utilitas Bagaimana kita tahu bahwa beberapa pengembang ingin menghindari gaya berjenjang? Ini adalah kebangkitan alat front-end “modern” – seperti kerangka kerja CSS-in-JS – yang dirancang khusus untuk tujuan tersebut. Bekerja dengan gaya terisolasi yang terbatas pada komponen tertentu bisa terasa seperti menghirup udara segar. Ini menghilangkan kebutuhan untuk menyebutkan nama – yang masih merupakan salah satu tugas front-end yang paling dibenci dan memakan waktu – dan memungkinkan pengembang untuk menjadi produktif tanpa sepenuhnya memahami atau memanfaatkan manfaat warisan CSS. Namun membuang Cascade CSS mempunyai masalah tersendiri. Misalnya, menyusun gaya dalam JavaScript memerlukan konfigurasi build yang berat dan sering kali menyebabkan gaya tercampur secara canggung dengan markup komponen atau HTML. Daripada mempertimbangkan konvensi penamaan dengan hati-hati, kami mengizinkan alat pembangunan untuk membuat penyeleksi dan pengidentifikasi secara otomatis untuk kami (misalnya, .jsx-3130221066), yang mengharuskan pengembang untuk mengikuti bahasa semu lainnya. (Seolah-olah beban kognitif untuk memahami apa yang dilakukan useEffects semua komponen Anda belum cukup!) Mengabstraksi lebih jauh tugas penamaan kelas ke perkakas berarti bahwa proses debug dasar sering kali dibatasi pada versi aplikasi tertentu yang dikompilasi untuk pengembangan, dibandingkan memanfaatkan fitur browser asli yang mendukung proses debug langsung, seperti Alat Pengembang. Sepertinya kita perlu mengembangkan alat untuk men-debug alat yang kita gunakan untuk mengabstraksi apa yang sudah disediakan web — semua demi menghindari “kesulitan” menulis CSS standar. Untungnya, fitur CSS modern tidak hanya membuat penulisan CSS standar menjadi lebih fleksibel namun juga memberi pengembang seperti kita lebih banyak kekuatan untuk mengelola kaskade dan membuatnya berfungsi untuk kita. CSS Cascade Layers adalah contoh yang bagus, namun ada fitur lain yang secara mengejutkan kurang mendapat perhatian — meskipun hal ini sekarang berubah karena baru-baru ini menjadi kompatibel dengan Baseline. CSS @scope Sesuai Aturan Saya menganggap aturan CSS @scope sebagai obat potensial untuk jenis kecemasan yang disebabkan oleh kebocoran gaya yang telah kami bahas, yang tidak memaksa kami untuk mengkompromikan keunggulan web asli untuk abstraksi dan perkakas pembangunan tambahan. “At-rule @scope CSS memungkinkan Anda memilih elemen dalam subpohon DOM tertentu, menargetkan elemen secara tepat tanpa menulis pemilih yang terlalu spesifik yang sulit untuk diganti, dan tanpa menggabungkan pemilih Anda terlalu erat dengan struktur DOM.”— MDN
Dengan kata lain, kita dapat bekerja dengan gaya terisolasi dalam kasus tertentu tanpa mengorbankan warisan, cascading, atau bahkan pemisahan dasar dari perhatian.yang telah menjadi prinsip panduan pengembangan front-end sejak lama. Selain itu, ia memiliki jangkauan browser yang luar biasa. Faktanya, Firefox 146 menambahkan dukungan untuk @scope pada bulan Desember, menjadikannya kompatibel dengan Baseline untuk pertama kalinya. Berikut perbandingan sederhana antara tombol yang menggunakan pola BEM versus aturan @scope:
Aturan @scope memungkinkan presisi dengan kompleksitas yang lebih sedikit. Pengembang tidak perlu lagi membuat batasan menggunakan nama kelas, yang pada gilirannya memungkinkan mereka menulis penyeleksi berdasarkan elemen HTML asli, sehingga menghilangkan kebutuhan akan pola nama kelas CSS preskriptif. Dengan hanya menghilangkan kebutuhan akan manajemen nama kelas, @scope dapat mengurangi ketakutan yang terkait dengan CSS dalam proyek-proyek besar.
Penggunaan Dasar
Untuk memulai, tambahkan aturan @scope ke CSS Anda dan masukkan pemilih akar ke gaya mana yang akan dicakup:
@ruang lingkup (
Jadi, misalnya, jika kita menerapkan gaya pada elemen
@ruang lingkup (nav) { a { /* Gaya tautan dalam cakupan navigasi */ }
a:aktif { /* Gaya tautan aktif */ }
a:active::before { /* Tautan aktif dengan elemen semu untuk gaya tambahan */ }
@media (lebar maksimal: 768 piksel) { a { /* Penyesuaian responsif */ } } }
Ini sendiri bukanlah fitur yang inovatif. Namun, argumen kedua dapat ditambahkan ke cakupan untuk membuat batas bawah, yang secara efektif menentukan titik awal dan akhir cakupan.
/* Elemen a apa pun di dalam ul tidak akan menerapkan gaya */ @scope (nav) hingga (ul) { sebuah { ukuran font: 14px; } }
Praktik ini disebut pelingkupan donat, dan ada beberapa pendekatan yang bisa digunakan, termasuk serangkaian penyeleksi serupa dan sangat spesifik yang dipasangkan erat ke struktur DOM, :not pemilih semu, atau menetapkan nama kelas tertentu ke elemen dalam
Kesimpulan Kerangka kerja CSS yang mengutamakan utilitas, seperti Tailwind, berfungsi baik untuk pembuatan prototipe dan proyek kecil. Namun manfaatnya cepat berkurang bila digunakan dalam proyek besar yang melibatkan lebih dari beberapa pengembang. Pengembangan front-end menjadi semakin rumit dalam beberapa tahun terakhir, termasuk CSS. Meskipun aturan @scope bukanlah solusi untuk semua hal, aturan ini dapat mengurangi kebutuhan akan peralatan yang rumit. Ketika digunakan sebagai pengganti, atau bersamaan dengan penamaan kelas strategis, @scope dapat membuat penulisan CSS yang mudah dikelola menjadi lebih mudah dan menyenangkan. Bacaan Lebih Lanjut
CSS @ruang lingkup (MDN) “CSS @scope”, Juan Diego Rodríguez (Trik CSS) Catatan Rilis Firefox 146 (Firefox) Dukungan Browser (CanIUse) Kerangka CSS Populer (Status CSS 2024) “The “C” dalam CSS: Cascade”, Thomas Yip (CSS-Trik) Pengenalan BEM (Dapatkan BEM)