Living Standard

Cara HTML berevolusi tanpa nomor versi dan realitas dukungan browser.

Daftar isi

HTML tidak lagi dirilis dalam paket bernomor yang diganti setiap beberapa tahun. Topik ini menjelaskan bagaimana standar HTML berpindah dari sistem versi ke dokumen tunggal yang terus diperbarui, bagaimana sebuah fitur baru masuk ke dalamnya, dan bagaimana kesiapan dukungan browser terhadap fitur itu diukur. Setelah topik ini dibaca, status sebuah fitur HTML dapat dinilai dari sumber resminya terlebih dahulu, bukan dari dugaan bahwa seluruh browser berperilaku sama.

Dari HTML4 ke HTML5#

HTML 4.01 yang diterbitkan W3C pada 1999 menjadi rujukan markup selama lebih dari satu dasawarsa. Percobaan merestrukturisasi HTML di atas XML, yang dikenal sebagai XHTML, memperketat aturan penulisan tanpa menjawab kebutuhan aplikasi web yang kian kompleks. Sejumlah pengembang browser kemudian mendirikan WHATWG pada 2004 untuk melanjutkan pengembangan HTML ke arah yang lebih pragmatis, dan W3C akhirnya mengadopsi draf HTML5 dari kelompok itu.

HTML5 diumumkan sebagai Rekomendasi W3C pada 2014 dan menjadi momen yang menyatukan kembali arah markup web. W3C menyusulnya dengan versi 5.1 dan 5.2, tetapi pusat gravitasi pengembangan tidak pernah berpindah dari WHATWG. Kesepakatan tahun 2019 antara W3C dan WHATWG menegaskan keadaan itu, yaitu HTML dan DOM dikembangkan pada satu dokumen tunggal yang diterbitkan WHATWG.

Living Standard dan hilangnya nomor versi#

Standar HTML saat ini adalah Living Standard yang diterbitkan WHATWG dan diperbarui terus-menerus tanpa versi yang dibekukan. Perubahan masuk ke dokumen ini secara bertahap, sehingga tidak ada momen peluncuran resmi seperti rilis perangkat lunak lama. Spesifikasi ini menyimpan riwayat revisinya secara terbuka, sehingga usia sebuah aturan markup dapat dilacak dari riwayat penyuntingannya, bukan dari nomor versi.

Istilah HTML5 yang masih sering terdengar berfungsi sebagai sebutan umum untuk markup modern, bukan penanda versi yang dapat diacu lagi. Versi browser sendiri kini menjadi penanda kecepatan penerapan Living Standard, sedangkan versi HTML tidak ada lagi. Pertanyaan yang berguna bukan lagi versi HTML apa yang digunakan sebuah halaman, melainkan fitur apa saja yang sudah tersedia di browser yang membukanya.

Bagaimana fitur baru masuk ke standar#

Fitur baru biasanya dimulai dari proposal, yaitu isu atau permintaan yang diajukan ke repositori publik WHATWG dan didiskusikan secara terbuka. Apabila usulan itu dianggap beralasan, penulis spesifikasi menuliskan aturannya ke dalam Living Standard, lengkap dengan detail pemrosesan yang harus diikuti setiap browser. Teks spesifikasi saja tidak cukup untuk mengubah web, karena aturan baru hanya terasa setelah browser membangunnya.

Implementasi di browser sering kali dimulai dalam kondisi eksperimental, misalnya di belakang tanda konfigurasi khusus pengembang. Masukan dari implementasi inilah yang memperhalus teks spesifikasi, karena ketidakjelasan aturan langsung terlihat ketika dua browser menghasilkan perilaku yang berbeda. Diagram berikut merangkum siklus hidup sebuah fitur sampai dukungannya dapat diandalkan.

Siklus hidup fitur HTML dari proposal sampai BaselineProposalusulan fiturdan diskusi publikSpesifikasiteks aturan ditulisdi Living StandardImplementasibrowser membangundan mengujinyaBaselinedukungan lintasbrowser terukurmasukan implementasi menyempurnakan teks spesifikasi
Siklus hidup fitur HTML dari proposal sampai Baseline

Baseline sebagai penanda kesiapan#

Baseline adalah penanda kesiapan fitur web yang dipublikasikan web.dev dan dirangkum dari data dukungan lintas browser inti, yaitu Chrome, Edge, Firefox, dan Safari. Sebuah fitur masuk status newly available ketika seluruh browser inti telah mendukungnya, kemudian naik ke status widely available setelah keadaan itu bertahan sekitar 30 bulan tanpa masalah besar. Penanda ini membuat keputusan penggunaan fitur menjadi terukur, karena statusnya dirangkum dari data dukungan yang sama yang digunakan tabel kompatibilitas.

Perbedaan statusnya terlihat pada dua fitur yang berdekatan. Elemen dialog didukung penuh oleh browser modern dan berstatus Baseline widely available, sehingga dapat digunakan tanpa rencana cadangan yang berarti. Sebaliknya, atribut popover baru mencapai Baseline newly available pada 2026, sehingga penggunaannya masih menyisakan browser lama yang membutuhkan penanganan cadangan.

Contoh markup berikut menempatkan keduanya bersebelahan. Dialog menampung pesan yang ditampilkan melalui metodenya, sedangkan panel munculan dibuka dan ditutup sepenuhnya lewat atribut tanpa satu baris skrip pun. Perbedaan status Baseline di antara keduanya tidak mengubah cara menulis markup, tetapi mengubah keputusan penanganan cadangan.

html Dua fitur dengan status Baseline berbeda
<dialog id="sapaan">
  <p>Dialog bekerja pada seluruh browser modern.</p>
</dialog>

<button type="button" popovertarget="panel">Buka panel</button>
<div id="panel" popover>Panel munculan deklaratif.</div>

Memeriksa dukungan sebelum menggunakan fitur#

Tiga sumber memadai untuk memeriksa dukungan sebuah fitur. Situs caniuse merangkum persentase dukungan per browser dan per versi, MDN menyediakan tabel kompatibilitas browser pada hampir setiap halaman dokumentasinya, dan halaman Baseline pada web.dev merangkum kesiapan penggunaannya secara umum. Data pengujian ketiganya saling melengkapi, sehingga ketidaksinkronan kecil di antaranya wajar terjadi.

Di luar tabel, dukungan tetap dapat dideteksi saat halaman berjalan melalui skrip. Teknik ini disebut feature detection, yaitu menguji keberadaan API sebelum fitur itu dipanggil. Pola ini menjadi jaring pengaman bagi fitur yang statusnya masih newly available, karena halaman tetap berfungsi ketika fiturnya tidak tersedia.

js Pendeteksian fitur dialog dan popover
// tidak-dijalankan
const punyaDialog = typeof window.HTMLDialogElement === "function";
const punyaPopover = "popover" in HTMLElement.prototype;

console.log(`dukungan dialog: ${punyaDialog}`);
console.log(`dukungan popover: ${punyaPopover}`);

Skrip di atas menggunakan API browser sehingga tidak dapat dieksekusi di lingkungan Node, tetapi polanya tetap terbaca. Keberadaan fitur diuji terlebih dahulu, dan percabangan setelahnya menyesuaikan perilaku halaman dengan hasil pengujian itu. Pola yang sama dapat diterapkan pada fitur HTML lain yang statusnya belum pasti.

Kesalahan umum#

  • Menganggap HTML5 sebagai versi akhir yang tidak berubah. Fitur baru terus masuk ke Living Standard, sehingga pengetahuan markup perlu diperbarui dari sumber resminya dan bukan dari catatan lama.
  • Menggunakan fitur baru tanpa memeriksa status dukungannya. Halaman yang tampak sempurna pada satu browser dapat rusak pada browser lain yang belum mengimplementasikan fitur tersebut.
  • Menilai dukungan dari pengalaman satu browser saja. Tabel kompatibilitas dan status Baseline menggantikan dugaan dengan data lintas browser.

Ringkasan#

  • HTML berkembang sebagai Living Standard WHATWG tanpa nomor versi, dan HTML5 kini berfungsi sebagai sebutan umum untuk markup modern.
  • Fitur bergerak melalui tahap proposal, spesifikasi, dan implementasi, dengan masukan implementasi yang menyempurnakan teks standarnya.
  • Baseline merangkum kesiapan dukungan menjadi newly available dan widely available, dengan dialog sebagai contoh yang widely available dan popover yang baru mencapai newly available pada 2026.
  • Dukungan fitur diperiksa melalui caniuse, tabel kompatibilitas MDN, dan pendeteksian fitur saat halaman berjalan.

Referensi#