D
P
0

WordPress & Elementor

Form GoHighLevel Jadi Tak Terlihat (Putih di Atas Putih) Setelah Tema Diubah Gelap↔Terang

25 Juni 2026·4 menit baca
Form GoHighLevel Jadi Tak Terlihat (Putih di Atas Putih) Setelah Tema Diubah Gelap↔Terang

Form-nya masih ada di sana. Labelnya kebaca jelas: "Nama", "Email", "Pesan". Tapi kolom isiannya seolah lenyap. Saya klik di area yang seharusnya jadi input, kursor teks muncul, saya ketik sesuatu, dan tidak ada apa-apa yang kelihatan. Ini terjadi tepat setelah saya membalik background satu section dari gelap ke terang di sebuah landing page klien yang menempelkan form GoHighLevel (GHL). Tidak ada error di console, tidak ada warning, tidak ada yang merah. Cuma input yang "hilang".

Begitu saya buka DevTools dan inspect salah satu field, gambarannya langsung jelas:

/* computed style pada input GHL */
input {
  color: rgb(255, 255, 255);      /* teks putih */
  background-color: transparent;   /* di atas section yang sekarang putih */
  border-color: transparent;
}

Teks putih di atas background putih. Saya ketik nama, hurufnya benar-benar ada di DOM, value-nya terisi, tapi mata tidak bisa melihatnya. Kalau arah temanya kebalik (section dari terang ke gelap), gejalanya beda lagi: bordernya jadi transparan dan field-nya seperti melebur ke background gelap. Pola yang sama, akar yang sama.

Kenapa ini terjadi

Kunci dari masalah ini ada di satu fakta yang gampang terlewat: form GHL ini di-inject ke DOM, bukan dirender di dalam iframe. Saya kira awalnya itu iframe seperti kebanyakan embed pihak ketiga, jadi saya santai. Ternyata salah. Saya inspect, dan elemen input, textarea, select-nya duduk langsung di dalam pohon DOM halaman saya, bukan di balik batas frame.

Bedanya besar sekali. Iframe punya document sendiri dan CSS host tidak menembus ke dalamnya — itu sebabnya embed yang berupa iframe biasanya kebal terhadap tema halaman. Tapi embed yang di-inject ke DOM tidak punya batas itu. Semua aturan CSS halaman saya mengalir masuk dan ikut meng-cascade ke field form GHL, sama persis seperti ke elemen lain di halaman.

Pada proyek ini themenya pakai Tailwind, dan di situlah pemicunya. Tailwind preflight dan aturan warna saya menyetel warna teks dan background mengikuti tema section. Waktu section-nya gelap, teks default disetel terang supaya kebaca. Begitu saya balik section itu jadi terang, saya cuma mengganti background section-nya — tapi warna teks yang diwariskan ke dalam input GHL tetap "terang". Hasilnya: teks putih, background putih. Form GHL sendiri tidak menetapkan warna eksplisit untuk input-nya, jadi ia pasrah mengikuti apa pun yang di-cascade dari host. Dan host saya yang baru saja saya ubah.

Yang bikin masalah ini licik adalah ia tidak pernah teriak. Tidak ada error. Validasi jalan, submit jalan, data masuk. Cuma secara visual field-nya tidak terlihat. Mudah sekali lolos dari review kalau kamu tidak kebetulan klik di kotak yang tepat.

Perbaikannya

Ada dua jalur, dan saya pakai keduanya tergantung siapa yang pegang kendali.

Jalur bersih — dari sisi pemilik form (GHL Custom CSS). Tempat paling benar untuk memperbaiki ini adalah di dalam GHL sendiri. GHL punya Custom CSS untuk form, dan di situ saya set warna input secara eksplisit supaya form-nya membawa warnanya sendiri ke mana pun ia ditempel:

/* Di GHL > Custom CSS milik form */
input,
textarea,
select {
  color: #111;
  background: #fff;
  border: 1px solid #ccc;
}

Dengan warna yang dipatok di level form, form jadi tahan banting: ditaruh di section gelap atau terang, input tetap kebaca karena tidak lagi menggantungkan nasibnya pada cascade host.

Jalur tambal — dari sisi tema. Kalau saya tidak punya akses ke akun GHL klien (sering kejadian), saya tambal dari sisi tema. Saya bungkus embed-nya dengan wrapper, misalnya .ghl-embed-wrap, lalu paksa warna input yang kontras apa pun tema section-nya:

.ghl-embed-wrap input,
.ghl-embed-wrap textarea,
.ghl-embed-wrap select {
  color: #111;
  background: #fff;
  border: 1px solid #ccc;
}

Ini efektif karena selector yang scoped ke wrapper mengalahkan warna umum yang diwariskan dari tema section, dan field-nya kembali kebaca tanpa peduli arah gelap atau terang. Saya anggap ini band-aid: ia menempel di repo saya, bukan di form, jadi kalau klien embed form yang sama di tempat lain, perlindungannya tidak ikut. Tapi sebagai perbaikan cepat yang aman, ini bekerja.

Satu langkah yang sekarang selalu saya lakukan duluan: pastikan dulu embed-nya iframe atau di-inject ke DOM. Buka DevTools, inspect field-nya. Kalau ia ada di dalam <iframe>, cascade kamu tidak menjangkaunya dan masalahnya pasti di tempat lain. Kalau input-nya duduk langsung di DOM kamu, kamu sedang berurusan dengan cascade — dan kamu tahu persis ke mana harus mengarah.

Pelajaran

Embed pihak ketiga yang di-inject ke DOM mewarisi cascade kamu; iframe tidak. Itu satu kalimat yang menjelaskan seluruh kejadian ini. Begitu saya membalik tema satu section, saya secara tidak sengaja mengubah warna teks yang menetes masuk ke input form yang bukan saya yang render — dan diam-diam membuatnya tak terlihat. Pelajarannya sederhana tapi gampang dilupakan: jangan pernah biarkan field form pihak ketiga bergantung pada warna warisan. Patok warna input secara eksplisit, idealnya di sisi pemilik form, atau setidaknya lewat aturan yang di-scope ke wrapper-nya. Dan sebelum menebak apa pun, cek dulu satu hal kecil yang menentukan segalanya: ini iframe, atau DOM?