Menggunakan Semantic Elements

Section Semantic HTML telah memperkenalkan tujuh elemen wilayah beserta maknanya. Membaca penjelasan dan membiasakan diri adalah dua hal yang berbeda — di tengah mengetik cepat, div tetap jadi pilihan default tangan, dan elemen semantik hanya dipasang saat sempat diingat. Kebiasaan ini membalik urutannya: semantik dulu, div terakhir.

Kuncinya satu pertanyaan kecil yang dilatih sampai menjadi refleks. Kita juga menyusun daftar ganti cepat untuk pola div yang paling sering muncul, lalu berlatih mengonversi satu blok asli milik Kedai Kopi Siti.

Pertanyaan Sebelum Menulis div #

Aturannya: setiap kali tangan mulai menulis <div>, berhenti satu detik dan tanya — “apakah ada elemen yang lebih tepat untuk tugas ini?”. Jika jawabannya tidak, div memang pilihan yang benar; elemen ini sah untuk wadah murni tanpa makna khusus. Jika jawabannya ya, tulis elemen yang lebih tepat itu sejak awal.

Mekanismenya berkaitan dengan cara makna dibaca. div tidak menyatakan apa pun, sementara header, nav, main, dan kawan-kawannya menyatakan perannya sendiri — dibaca oleh pembaca layar, mesin pencari, dan rekan tim tanpa perlu satu class pun. Manfaat lengkapnya sudah kita bedah di chapter Apa itu Semantic HTML. Untuk kebiasaan sehari-hari, daftar ganti berikut menutup mayoritas kasus:

Latihan Konversi #

Sekarang kita bedah satu blok asli — kepala halaman menu milik Kedai Kopi Siti, ditulis dalam gaya lama:

<div class="atas">
  <div class="logo">Kedai Kopi Siti</div>
  <div class="menu">
    <ul>
      <li><a href="index.html">Beranda</a></li>
      <li><a href="menu.html">Menu</a></li>
      <li><a href="kontak.html">Kontak</a></li>
    </ul>
  </div>
</div>

Berikut versi semantiknya:

<header>
  <p><strong>Kedai Kopi Siti</strong></p>
  <nav aria-label="Menu utama">
    <ul>
      <li><a href="index.html">Beranda</a></li>
      <li><a href="menu.html">Menu</a></li>
      <li><a href="kontak.html">Kontak</a></li>
    </ul>
  </nav>
</header>

Hasil render keduanya sama persis — nama kedai dan tiga tautan menurun — karena perbedaannya bukan tampilan, melainkan makna. Mari kita bedah baris-per-baris:

1. <header> (baris 1): menggantikan <div class="atas"> — pembuka wilayah halaman, tanpa perlu class pembantu.
2. <p><strong>...</strong></p> (baris 2): teks nama kedai; logo berupa teks cukup ditandai kuat, nanti tinggal distyle dengan CSS.
3. <nav aria-label="Menu utama"> (baris 3): menggantikan <div class="menu"> — pembaca layar langsung mengumumkan “menu utama” tanpa membaca nama class.
4. <ul> dan tiga <li> (baris 4-8): daftar tautan, sama seperti sebelumnya — list memang sudah elemen yang tepat, tidak perlu diubah.
5. Penutup </nav></header> (baris 9-10): tumpukan yang jelas; setiap penutup menyebut pasangannya sendiri.

Kesetaraan tampilan kedua versi bisa diverifikasi langsung — kedua blok di atas dirender berdampingan dengan gaya minimal yang sama:

Tautan pada kedua panel menunjuk berkas yang tidak tersedia di dalam bingkai — bila diklik, muat ulang halaman ini untuk mengembalikan demo; yang dibandingkan di sini adalah struktur dan tampilannya.

Kedua panel tidak bisa dibedakan dari layar: nama kedai di atas, tiga tautan menurun di bawahnya. Perbedaan versi semantik memang tidak pernah sampai ke mata — pembaca layar mengumumkan nav sebagai “Menu utama” dan mengenali header sebagai pembuka wilayah, sementara tumpukan div di panel pertama tidak mengumumkan makna apa pun. Selector CSS juga bekerja lebih tenang: nav ul menyasar daftar di navigasi mana pun tanpa bergantung pada nama class buatan.

Perhatikan pola umumnya: markup versi lama memakai class untuk menyimpan makna (atas, menu), sementara versi semantik memindahkan makna itu ke nama elemen — class tinggal dipakai saat benar-benar perlu sebagai hook CSS.

Ringkasan #

• Kebiasaan inti: satu pertanyaan sebelum setiap div — “ada elemen lebih tepat?”.
• Daftar ganti cepat: header, nav, main, footer, dan article dalam section untuk konten berulang.
• Latihan konversi memperlihatkan hasil render yang sama dengan makna yang berbeda — makna inilah yang dibawa pembaca layar dan mesin pencari.

Chapter berikutnya menghadapi penyakit sebaliknya: markup yang menumpuk jauh lebih banyak dari yang dibutuhkan.