Konflik Aturan CSS

Sampai di sini kita sudah menguasai potongan-potongan cascade: origin & importance, layers, specificity, dan source order. Chapter ini merangkainya menjadi satu prosedur keputusan yang bisa dijalankan setiap kali dua aturan bertengkar memperebutkan satu property. Kita latih pada tiga skenario yang paling sering muncul di proyek nyata, lalu melihat lapisan sumber gaya yang biasa beroperasi dalam satu halaman.

Prosedur Keputusan Cascade #

Ketika sebuah elemen menampilkan gaya yang tidak kita duga, jalankan urutan pemeriksaan berikut secara berurutan dan berhenti pada kriteria pertama yang memisahkan kandidat:

1. Origin & importance — apakah ada deklarasi !important atau deklarasi dari origin berbeda (user-agent, user, author)? Kelompok yang lebih kuat langsung menang.
2. Cascade layers — bila CSS memakai @layer, bandingkan urutan layer; layer yang dinyatakan lebih akhir menang pada deklarasi normal.
3. Specificity — bandingkan bobot (a, b, c) dari kedua selector; bobot lebih tinggi menang.
4. Source order — bila semuanya seri, deklarasi yang ditulis paling akhir menang.

Dengan empat langkah ini, setiap konflik punya satu jawaban yang pasti. Tiga skenario berikut membuktikannya.

Skenario 1: Specificity Seri, Urutan Menentukan #

.notifikasi {
  color: #475569;
}

.notifikasi {
  color: #14503a;
}

Kedua selector identik sehingga specificity seri (0, 1, 0), origin sama, dan tidak ada layer. Pemeriksaan berjalan sampai langkah empat: deklarasi kedua ditulis paling akhir, sehingga teks notifikasi tampil hijau pekat. Mencurigai specificity di sini hanya membuang waktu — urutannya yang bicara.

Skenario 2: Specificity Berbeda, Bobot Menentukan #

.sidebar .menu a {
  color: #475569;
}

a.tautan-aktif {
  color: #14503a;
}

Selector pertama berbobot (0, 1, 2) dan selector kedua berbobot (0, 1, 1). Origin sama dan tidak ada layer, tetapi langkah tiga sudah memisahkan keduanya pada kolom c: dua element mengalahkan satu. Tautan yang membawa kedua class sekaligus akan tampil abu-abu, berapa pun urutan penulisannya. Solusi yang benar bukan memindahkan rule, melainkan menaikkan bobot — misalnya menjadi .sidebar .menu a.tautan-aktif.

Skenario 3: !important Memutar Hasil #

.sidebar .menu a {
  color: #475569;
}

a.tautan-aktif {
  color: #14503a !important;
}

Susunan specificity masih sama seperti skenario kedua, tetapi langkah satu berhenti lebih dulu: deklarasi !important berada di kelompok important yang mengalahkan seluruh deklarasi normal. Tautan aktif pun tampil hijau pekat. Perhatikan bahwa specificity tidak dihitung sama sekali pada langkah ini — itulah mengapa menambah class di selector pertama tidak akan mengubah hasilnya, dan jalur keluar yang sehat adalah menghapus !important itu sendiri.

Sebagai penutup latihan, demo berikut memuat tiga rule yang semuanya menargetkan paragraf yang sama dan mengatur color:

Prosedurnya: p berbobot (0, 0, 1) tersingkir di langkah specificity, .promo p (0, 1, 1) juga kalah, dan .promo p.sorot (0, 2, 1) menang tanpa perlu sampai ke source order. Tiga deklarasi color masuk ke browser, satu keluar sebagai pemenang.

Sumber Gaya yang Berlapis dalam Satu Halaman #

Halaman produksi jarang hanya memuat satu stylesheet. Gaya datang berlapis, dan urutan lapisan inilah yang menjelaskan dari mana konflik berasal:

Urutan pemuatan stylesheet sebaiknya mengikuti tabel di atas: reset dulu, lalu library, tema, dan override halaman terakhir. Dengan begitu penimpaan antar-lapisan mengandalkan source order yang sehat, bukan perlombaan specificity — dan kasus !important bisa ditekan seminimal mungkin.

Ringkasan #

Konflik CSS selalu punya satu penyelesaian: jalankan kriteria cascade berurutan — origin & importance, layers, specificity, lalu source order — dan berhenti pada yang pertama memisahkan kandidat. Skenario specificity seri ditentukan urutan, skenario bobot berbeda ditentukan specificity, dan !important memotong seluruh penilaian. Lapisan sumber gaya dari browser hingga override halaman menjelaskan asal konflik, sementara panel Styles di DevTools menampilkan vonisnya secara langsung. Chapter berikutnya menjadikan DevTools alat utama kita untuk membaca dan memperbaiki konflik tersebut.