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:

You May Also Like

Enjoyed This Article?

Get weekly tips on growing your audience and monetizing your content — straight to your inbox.

No spam. Join 138,000+ creators. Unsubscribe anytime.

Create Your Free Bio Page

Join 138,000+ creators on Seemless.

Get Started Free