Ikon Footer yang Hilang Karena Kartunya Jadi Putih

Commit d6b73b2 bikin kartu footer jadi putih solid di light mode. Saya cek, kelihatannya oke. Tapi pas scroll ke bawah, ikon GitHub dan badge Next.js di footer nggak keliatan. Hilang total.

Saya cek lewat inspect element. Tag SVG masih ada di komponen Footer. Tapi warnanya putih, di atas background putih.

Dugaan awal: mungkin saya kehapus pas refactor. Ternyata enggak. Ikon-nya dari awal memang hardcode putih heks. Warna yang sama persis sama background kartu yang baru saya perbaiki. Sebelum commit d6b73b2, kartu footer itu transparan atau gelap — ikon putih keliatan normal. Begitu background-nya diganti putih solid, white-on-white jadi invisible.

Perbaikan satu bagian nge-expose bug di bagian lain. Commit yang bikin kartu bagus justru bikin ikon hilang. Paradoks kecil yang sering muncul di pekerjaan tema: perubahan yang secara lokal benar bisa memindahkan kegagalan ke tetangganya, dan korbannya baru kelihatan di bagian halaman yang tidak ikut disentuh.

Ganti Putih Hardcode jadi Variabel Tema

Semua referensi #ffffff pada fill dan stroke ikon di Footer.tsx diganti var(--foreground). Nilai variabel foreground sudah didefinisikan di berkas styles global per tema: hitam di light, putih di dark. Ikon otomatis kontras sama background apapun, tanpa nambah conditional logic di JavaScript. Yang saya hapus bukan cuma satu baris kode, tapi satu kelas masalah: komponen yang menyimpan asumsi tema sendiri di dalamnya. Selama warna ditulis langsung, setiap kali tema berubah, semua komponen penyimpan asumsi itu jadi kandidat bug berikutnya.

CSS custom properties memang dirancang buat kasus kayak gini. Nilai yang diakses lewat var() dipakai ulang di seluruh dokumen, tinggal ganti definisi di satu tempat [6]. Bukan cuma soal DRY, tapi biar elemen otomatis adaptif tanpa harus mikir "kalau light mode warnanya X, kalau dark mode warnanya Y" di tiap komponen.

Gradient Neon yang Pudar di Atas Putih

Masalah kedua: text-gradient-tri di footer. Di dark mode, gradient neon hijau-biru-ungu keliatan vivid. Di light mode, gradient yang sama pudar. Warna neon di atas putih itu kayak neon sign nyala di siang bolong, ada, tapi nggak keliatan.

Solusinya: bikin varian light di globals.css pakai palet brand GitHub yang lebih pekat.

.light .text-gradient-tri {
  background: linear-gradient(90deg, #1a7f37, #0969da, #8250df);
}

Hijau, biru, ungu, tiga warna yang identik sama brand GitHub. Lebih gelap dari neon aslinya, tapi justru itu yang dibutuhkan biar kontras di atas background putih.

Pola varian per tema kayak gini udah standar di Tailwind, bg-white dark:bg-gray-800 contohnya [7]. Bedanya, saya pakai class .light manual di parent element, karena pergantian tema di project ini dipegang class dark di elemen html. Bukan hack, tapi juga bukan pakai mekanisme bawaan Tailwind.

Saya lebih suka pendekatan ini daripada menambah varian dark: ke tiap elemen satu per satu, karena di project ini logika tema sudah dipegang variabel CSS, bukan utility Tailwind. Aturan yang saya ambil dari insiden ini: warna yang harus berubah mengikuti tema ditulis sebagai variabel tema, hex literal hanya untuk warna yang memang sama di semua tema. Kasus serupa pernah saya alami waktu membenahi warna accent yang cakep di dark tapi pudar di light.

Yang bikin mikir bukan fix-nya, itu cuma ganti hex ke variable. Yang bikin mikir itu waktunya bug muncul. Tapi kapan bug-nya muncul itu yang bikin saya mikir. Nggak pas dark mode. Nggak pas deploy pertama. Muncul pas saya perbaiki light mode di commit sebelumnya.

Kalau dari awal ikon-nya pakai var(--foreground) instead of #ffffff, masalah ini nggak akan pernah ada. Satu hardcoded hex literal yang detonasi-nya bergantung di mana else yang berubah di codebase [7]. Nilai warna yang nempel tema seharusnya pakai variabel yang juga nempel tema, hex literal warna apapun di component yang aware theme itu bom waktu yang cuma belum ketemu detonator-nya.

---

Sumber

• MDN Web Docs, Using CSS custom properties [6]
• Dokumentasi Tailwind CSS, Dark Mode [7]