Chapter Debugging Specificity pada section Cascade sudah menjelaskan cara membaca vonis cascade dan strategi memperbaiki konfliknya. Chapter ini melengkapinya dengan fokus yang berbeda: alur kerja DevTools yang konsolidasi — dari membaca panel Styles, melacak asal setiap rule, memfilter seluruh rule yang menyentuh satu property, sampai satu fitur yang sering luput: memaksa state :hover dan :focus tanpa benar-benar menghover atau menekan Tab. Fitur terakhir itu penting karena rule pseudo-class justru paling sulit diperiksa dengan cara biasa.

Alur Kerja Terpadu di Panel Styles #

Seluruh pemeriksaan specificity bermuara pada satu panel. Urutan membacanya bisa dirangkum begini:

text 
1. Inspect elemen → panel Styles menampilkan semua rule yang menargetkannya
2. Baca dari atas ke bawah — rule pemenang selalu paling atas
3. Deklarasi dicoret = kalah; hover selector → lihat asal berkas & baris
4. element.style = gaya inline (atribut style atau suntingan JavaScript)
5. Ketik nama property di kotak Filter → semua peserta konflik tampil
6. Uji perbaikan dengan mencentang atau menyunting deklarasi langsung

Tiga detail pada alur itu perlu diperhalus. Pertama, mengarahkan kursor ke selector akan memperlihatkan lokasi sumbernya — nama berkas dan nomor baris pada Chrome, sering kali berupa tautan yang bisa diklik untuk melompat ke berkas sumber. Detail ini menyelesaikan pertanyaan “rule ini datang dari mana?” dalam satu gerakan, penting saat halaman memuat lima stylesheet sekaligus.

Kedua, blok element.style di posisi paling atas menampung gaya inline: berasal dari atribut style di HTML, atau dari JavaScript yang menyunting gaya saat halaman berjalan. Bila blok ini berisi deklarasi yang tidak kita tulis, cari kode JavaScript yang memanipulasinya — specificity inline tidak bisa dikalahkan oleh rule biasa, jadi blok ini sering menjadi tersangka utama konflik yang tidak kunjung selesai.

Ketiga, kotak Filter di atas panel Styles menerima nama property: ketik color, dan hanya rule yang menyentuh color yang tampil — termasuk yang dicoret. Untuk kebutuhan sejenis, panel Computed menawarkan jalur sebaliknya: cari property pada daftar terhitung, lalu klik panah di sampingnya untuk melompat ke rule yang menang di panel Styles. Dua jalur ini menjawab dua pertanyaan berbeda: “siapa saja yang ikut bersaing?” dan “siapa pemenangnya?”.

Force State: Menguji Pseudo-class tanpa Interaksi #

Di atas panel Styles terdapat tombol berlabel :hov (Toggle Element State). Mencentang salah satu pilihan — :hover, :active, :focus, :focus-visible, :focus-within, :target — memaksa elemen seolah sedang berada di state itu, dan seluruh rule yang cocok langsung berlaku:

css 
.tombol-utama {
  background-color: #14503a;
  color: #ffffff;
}
.tombol-utama:hover {
  background-color: #0f3d2c;
}
.tombol-utama:focus-visible {
  outline: 3px solid #b45309;
  outline-offset: 3px;
}

Ini adalah cara tercepat memverifikasi bahwa rule focus memang ada dan bernilai benar. Demo berikut menampilkan state aslinya — arahkan kursor lalu tekan Tab di dalam bingkai:

Dua catatan menjaga agar fitur ini tidak disalahpahami. Pertama, emulasi :visited dibatasi privacy browser dan hanya berlaku pada sebagian kecil property warna. Kedua, force state adalah alat verifikasi CSS, bukan pengganti uji nyata: ring fokus tetap harus diperiksa dengan menekan Tab sesungguhnya, sesuai alur pada chapter Focus dan Keyboard.

Contoh Konflik yang Terbaca Jelas #

Benturan specificity paling sederhana terjadi pada property yang ditulis dua kali dengan bobot sama — pemenangnya urutan, bukan bobot:

css 
.kartu-profil {
  color: #52606d;
  color: #14503a; /* menang: specificity sama, ditulis lebih bawah */
}

Panel Styles menampilkan kedua deklarasi berdampingan, dengan yang pertama dicoret — bukti visual bahwa urutan sumber yang memutuskan. Konflik semacam ini juga yang pertama dilaporkan alat linting, seperti yang akan kita lihat pada chapter Validasi CSS.

Demo berikut memuat satu tombol yang ditargetkan tiga rule dengan bobot berbeda, plus satu rule :hover. Jalankan di DevTools untuk membaca hasilnya:

background-color dimenangkan rule .panel-aksi .tombol-simpan (0, 2, 0), sedangkan border jatuh ke .tombol-simpan karena rule berbobot tinggi itu tidak menulis border sama sekali. Inspect tombolnya untuk membaca cerita ini di panel Styles — lengkap dengan coretan, asal berkas, dan hasil pemfilteran kata background-color yang menampilkan ketiga peserta konflik dalam satu layar.

Ringkasan #

Alur kerja specificity yang konsolidasi berjalan di satu tempat: panel Styles dibaca dari atas ke bawah, deklarasi dicoret sebagai penanda yang kalah, selector yang dihover membuka asal berkasnya, element.style menandai gaya inline atau suntingan JavaScript, dan filter per property — dari Styles maupun Computed — memisahkan pertanyaan “siapa peserta” dari “siapa pemenang”. Fitur force state menutup celah terbesarnya: rule :hover dan :focus-visible kini bisa diverifikasi tanpa interaksi, meskipun uji keyboard sungguhan tetap wajib. Setelah gaya dan konfliknya kita kuasai, babak berikutnya memastikan layout tetap sehat di semua ukuran layar.