Membaca HTML di DevTools

Saat halaman tampil tidak sesuai harapan, pertanyaan pertama yang perlu kita jawab bukan “apa yang salah dengan kode saya”, melainkan “apa yang sebenarnya dipahami browser”. DevTools menyimpan jawabannya: panel Elements menampilkan DOM — struktur hasil pembacaan browser — bukan file HTML yang kita tulis. Membedakan keduanya adalah keterampilan dasar seluruh debugging HTML.

Chapter ini membahas perbedaan antara tampilan sumber dan panel Elements, normalisasi yang dilakukan parser, trik menelusuri elemen dengan cepat, serta kebiasaan mengedit DOM secara sementara untuk bereksperimen.

View-Source dan Elements: Dua Tampilan Berbeda #

Aturannya sederhana: browser menyimpan dua versi halaman. Versi pertama adalah file HTML mentah yang diunduh; versi kedua adalah DOM yang dibangun dari file tersebut. View-Source (Ctrl+U pada Windows dan Linux; Cmd+Opt+U pada macOS) menampilkan versi pertama — teks persis seperti yang tertulis di penyimpanan. Panel Elements menampilkan versi kedua: hasil parsing, lengkap dengan koreksi parser dan seluruh perubahan yang dilakukan JavaScript setelah halaman berjalan.

Keduanya bisa berbeda, dan perbedaan tersebut justru informasi diagnostik paling berharga: “saya menulis A, browser memiliki B” adalah titik awal penelusuran yang jauh lebih tepat daripada menebak-nebak.

Normalisasi: Parser Menyunting Diam-Diam #

Kasus yang hampir semua orang jumpai: tabel. Standar HTML menempatkan baris tabel di dalam tbody. Ketika kita menulis tr langsung di bawah table, parser memindahkan seluruh baris ke dalam tbody yang dibuatnya sendiri — proses ini disebut normalisasi. Berikut file yang kita tulis:

<table>
  <tr>
    <td>Kopi susu</td>
    <td>Rp18.000</td>
  </tr>
</table>

Dan berikut isi panel Elements pada halaman yang sama:

<table>
  <tbody>
    <tr>
      <td>Kopi susu</td>
      <td>Rp18.000</td>
    </tr>
  </tbody>
</table>

Mari kita telaah dua blok di atas:

1. Baris 1 (<table> pada blok pertama): tabel ditulis tanpa tbody — diterima parser, tetapi bukan bentuk akhirnya di DOM.
2. Baris 2 (<tbody> pada blok kedua): muncul di DOM padahal tidak pernah kita tulis; parser menambahkannya sendiri, tanpa pesan apa pun.
3. Baris 3–5 (<tr>, <td>): seluruh baris dipindahkan ke dalam tbody baru tersebut; urutan dan isi teksnya tetap sama.

Panel Elements adalah antarmuka milik browser itu sendiri — tidak ada cara menyematkannya sebagai demo di dalam halaman ini. Buktikan sendiri dalam satu menit: simpan menu.html di atas sebagai berkas, buka di browser, tekan F12, lalu bandingkan pohon pada panel Elements dengan kedua blok tersebut — tbody yang tidak pernah kita tulis akan tampil di sana.

Gejala serupa muncul pada markup bermasalah lainnya: tag yang salah tempat, elemen yang tidak ditutup — parser menyelesaikannya menurut aturannya, dan Elements menampilkan hasil keputusan tersebut. Chapter Kesalahan Nesting membedah tiga kasusnya satu per satu.

Trik Menelusuri yang Cepat #

Empat kebiasaan yang mempercepat pembacaan panel Elements:

1. Ctrl+F di panel Elements — membuka kotak cari; ketik nama tag, id, atau class untuk melompat langsung ke simpulnya.
2. Arahkan kursor ke simpul — halaman menandai elemen yang bersangkutan dengan highlight; elemen yang meleset dari posisinya langsung terlihat.
3. Periksa panel Styles — setiap simpul menampilkan CSS yang sedang berlaku padanya; kecurigaan “styling tidak menempel” diuji di sini sebelum menyentuh markup.
4. Dobel-klik simpul — sunting tag, atribut, atau teks langsung di panel; halaman menampilkan hasilnya seketika. Muat ulang halaman dan semuanya kembali seperti semula karena file di penyimpanan tidak pernah tersentuh.

Dengan kemampuan membaca DOM, langkah berikutnya adalah memahami apa sebenarnya DOM itu: pohon objek yang hidup di memori browser. Chapter berikutnya membedah strukturnya dari akar sampai simpul teks.