Mengapa HTML sendiri tidak mendukung fitur `include`?

• Kebutuhan untuk menghindari pengulangan header yang sama di banyak halaman adalah hal mendasar, tetapi HTML tidak memiliki tag include native untuk menanganinya secara langsung
• Para pengembang selama ini menyelesaikan masalah yang sama lewat cara-cara tidak langsung seperti JavaScript fetch, direktif server, generator situs statis, bahasa template, bahasa backend, dan Web Components
• <iframe> adalah cara yang paling dekat dengan HTML murni, tetapi tidak cocok untuk tujuan ini dari sisi performa, aksesibilitas, dan kegunaan, serta terasa canggung secara keseluruhan
• CSS bisa mengimpor CSS dan JavaScript bisa mengimpor JavaScript, tetapi HTML tidak bisa mengimpor HTML, sehingga konsistensi platform web tampak terganggu
• Dampak pada preload scanner, layout yang bergeser karena pemuatan asinkron, include bertingkat dan sirkular, bertambahnya request, pembatasan domain, serta kemungkinan rendahnya permintaan tetap menjadi hambatan standardisasi

---

Kebutuhan dasar untuk menggunakan kembali potongan HTML yang berulang

• Masalah ini terlihat jelas saat harus menaruh header yang sama di tiga halaman: index.html, about.html, dan contact.html
• Daripada menyalin kode yang sama tiga kali, terasa wajar untuk membuat header sekali lalu meng-include-nya di banyak halaman
• Jika jumlah halaman bertambah menjadi ribuan, ini bukan lagi sekadar soal kenyamanan, melainkan masalah pencegahan duplikasi kode

Beragam solusi yang sudah ada

• Cara mengambil dan menyisipkan potongan HTML sebenarnya sudah dimungkinkan di banyak alat dan lapisan
  • JavaScript bisa mengambil HTML dengan fetch lalu menyisipkannya dengan insertAdjacentElement
  • Ada juga Server Side Includes, direktif server web yang sudah lama ada
  • Ini bisa ditangani lewat fitur generator situs statis seperti Jekyll include
  • Task runner seperti gulp-include juga dapat digunakan
  • Bahasa template seperti Handlebars partials umumnya menyediakan fitur include
  • Bahasa backend seperti PHP juga bisa menghasilkan HTML secara dinamis, misalnya dengan include
  • Ada pula pendekatan Web Component yang khusus untuk include
• <iframe> secara teknis adalah cara untuk mengambil HTML lain hanya dengan HTML murni, tetapi untuk tujuan ini memiliki masalah besar dalam performa, aksesibilitas, dan kegunaan
• Ada juga pilihan untuk sama sekali tidak memakai include dan mengandalkan fitur find/replace yang kuat

Justru tidak ada di HTML itu sendiri

• Semua cara di atas tetap bukan pendekatan “mengambil HTML dengan satu tag HTML lalu menaruhnya di lokasi ini”
• Seperti <img> yang mengambil gambar dan menaruhnya di posisi tersebut, HTML tidak memiliki tag deklaratif langsung untuk “ambil HTML ini dan masukkan ke sini”
• Di ShopTalk Show, pertanyaan yang sama juga dibahas bersama Jake Archibald dan Dave Rupert

Titik yang terasa bertentangan dengan arus platform web

• Standar web dan browser sering menyerap hal-hal yang sebelumnya terus-menerus diselesaikan pengembang menjadi fitur platform
• Untuk alur yang sebelumnya mengandalkan JavaScript pihak ketiga dalam menangani tanggal, kini ada Temporal
• Untuk kebutuhan transisi halaman yang dulu banyak ditangani framework, kini ada View Transition API
• Untuk area library yang dipakai demi menempatkan elemen dengan aman, kini ada CSS anchor positioning
• Dalam situasi ketika hampir semua situs web membutuhkan penggunaan ulang potongan HTML dan masing-masing memakai alat nonstandar yang berbeda, ketiadaan HTML include tampak seperti kekosongan yang tidak biasa

Mengapa HTML include sulit menjadi standar

• Dari sudut pandang browser dan ekosistem, HTML include membawa berbagai beban
  • Bisa merusak preload scanner dan berdampak buruk pada performa web
  • Jika harus bersifat asinkron, pengalaman layar bisa terasa bergeser atau meloncat saat memuat
  • Bisa menambah kompleksitas yang merusak kesederhanaan atau kemurnian HTML
  • Penanganan include bertingkat dan include sirkular bisa menjadi sulit
  • Penyedia web hosting bisa menentangnya karena jumlah request meningkat
  • Berbeda dari gambar, CSS, dan JavaScript, HTML mungkin memerlukan pembatasan yang lebih ketat saat diambil dari domain lain
  • Bisa saja ada masalah lain yang tidak tercantum di daftar ini
  • Bisa juga sebenarnya permintaan untuk fitur ini tidak sebesar yang dibayangkan
• Alih-alih jawaban pasti, ini lebih merupakan penelusuran alasan tentang mengapa HTML tidak bisa meng-include HTML secara langsung

[GN⁺]

Pendapat di Hacker News

• Secara historis, HTML adalah aplikasi dari SGML, dan SGML mendukung include
  Kita bisa mendefinisikan “entity” baru, dan jika membuat entity “system”, nantinya bisa dirujuk lalu disubstitusikan. SGML itu kompleks, sehingga ada beberapa upaya untuk menyederhanakan HTML, dan dalam prosesnya fitur ini juga hilang

  • HTML sempat melewati jalur XML lewat XHTML, dan XML punya XInclude, tetapi itu bukan fitur wajib
  • Ini referensi yang menarik, jadi saya berencana mencari tahu lebih lanjut
    Tag tersebut tampaknya menyertakan atau meng-embed halaman HTML lain. Halaman HTML yang di-embed: https://www.w3schools.com/tags/tag_object.asp
  • Itu sendiri merupakan permukaan serangan yang lengkap
    https://en.wikipedia.org/wiki/Billion_laughs_attack
  • Fitur itu juga ada di DTD yang dipakai di HTML 4 ke bawah dan XML, dan kemungkinan berasal dari SGML

• Ini adalah lubang kelinci yang saya masuki pada akhir 90-an, dan sampai sekarang belum keluar
  Saya dulu webmaster situs web Analog Science Fiction, dan karena harus membuat begitu banyak halaman statis dengan header dan sidebar yang sama, rasanya hampir gila. Setelah mencari-cari, saya menemukan server-side include Apache, dan bahkan sebelum mengenal istilah DRY, saya sudah bisa membuatnya DRY. Ada yang bilang iframe sudah cukup, tetapi sebenarnya tidak. iframe tidak melebar/menyesuaikan tinggi mengikuti ukuran konten, dan solusi sisi server membutuhkan server. Saya tidak mengerti mengapa tidak boleh ada cara sederhana di sisi klien, dan ini pertanyaan yang layak dipertimbangkan sekarang ketika banyak kekesalan dalam pengembangan web sedang diperbaiki

  • Server-side include memang yang terbaik
    Saat mulai membuat “web stuff” bersama teman pada pertengahan 90-an, konsep DRY terasa alami begitu saja. ISP dial-up waktu itu tidak memblokir penggunaan .htaccess di ruang web pengguna, jadi kami bisa mengaktifkan server-side include, dan belakangan juga menemukan cara mengaktifkan CGI. Saya bahkan menulis web shell sederhana dengan Perl untuk menjelajahi boks web server
  • Karena alasan seperti ini saya jadi menyukai https://htmx.org
    Ini adalah library kecil berukuran 10KB yang menambahkan kemampuan inti semacam import dinamis untuk HTML statis ke HTML
  • Bagian “iframe tidak melebar menyesuaikan konten” sebenarnya dulu termasuk dalam rencana awal
    https://caniuse.com/iframe-seamless
  • Bahkan di Netscape tahun 1996, hal semacam ini bisa dilakukan. Saya masih menjalankan server situs web yang memakai cara ini
    Hal yang selalu mengganggu dari frame adalah frame bertindak terlalu pintar. Saat klik kanan lalu refresh, saya tidak ingin hanya HTML frame itu saja yang dimuat ulang. Saya mengerti niatnya untuk melakukan cache terpisah, tetapi frame dan cache seharusnya menyelesaikan masalah yang berbeda; ketika keduanya dicampur, hasilnya keduanya jadi serba tanggung. Menurut saya HTML include harus berperilaku sebodoh mungkin. Cukup tempelkan teks include di lokasi include, lalu browser menerima teks hasilnya. Jika ingin men-cache navigasi yang sama di semua halaman secara terpisah, tambahkan atribut cache dan selesaikan masalah itu secara independen. Mungkin orang bisa meyakinkan saya bahwa include perlu melakukan lebih banyak hal, tetapi perilaku bodoh adalah fitur, bukan bug
  • Solusi terbaik adalah menghasilkan dokumen statis dengan template engine

• Usulan fitur ini disebut HTML Imports, dan dibuat sebagai bagian dari pekerjaan Web Components
  Ada deskripsi “HTML Imports are a way to include and reuse HTML documents in other HTML documents”, dan dokumen rencananya ada di https://www.w3.org/TR/html-imports/

  • Ini sesuai dengan komentar [1] di artikel yang menyebut kurangnya permintaan, kurangnya antusiasme vendor, dan sebagainya
    Namun alasan-alasan seperti ini nyaris seperti bukan alasan, karena sebenarnya tidak menjelaskan apa pun. Sulit dipercaya bahwa permintaannya rendah, padahal fitur ini terus diminta selama 20 tahun dan ada berbagai implementasi shim yang dibuat dengan script, mesin backend, dan lain-lain. Penolakan vendor juga tidak menjelaskan mengapa mereka sampai menolak hingga membalikkan implementasi yang sudah ada. “Dampak keamanan” juga terasa aneh, karena dengan tag script kita sudah bisa mengambil HTML lintas origin lalu melakukan document.write(). Saya penasaran mengapa script yang melakukan document.write() dianggap baik-baik saja, sementara tag HTML yang melakukan hal yang sama menjadi masalah besar. Saya memahami kekhawatiran keamanan bahwa orang bisa secara instan menggandakan halaman utama Google, tetapi itu tampaknya mudah diselesaikan dengan CORS
    [1] https://frontendmasters.com/blog/seeking-an-answer-why-cant-...
  • HTML Imports juga berada di arah yang mirip, tetapi berbeda dari fitur yang dibicarakan artikel blog ini
    HTML seharusnya diimpor dan ditampilkan pada posisi tertentu dalam dokumen, tetapi HTML Imports tidak bisa melakukan itu tanpa JavaScript. Untuk detailnya, lihat https://github.com/whatwg/html/issues/2791#issuecomment-3112...
  • Agar adil, fitur itu memang cukup kompleks
    Seingat saya, setelah import, template harus diinstansiasi dengan JavaScript, dan bukan sekadar satu tag sederhana
  • Jika melihat https://caniuse.com/imports, Firefox juga pernah memilikinya lewat flag pengaturan
  • HTML Imports jauh lebih kompleks daripada include yang diminta artikel ini

• Netscape 4 memiliki fitur ini sebagai inflow layer
  https://web.archive.org/web/19970630074729fw_/http://develop...
  https://web.archive.org/web/19970630094813fw_/http://develop...

  • Seingat saya, tindakan mengubah atribut SRC cukup sering menyebabkan crash, dan fiturnya juga segera dihapus
    Saya ingat pernah mencobanya di versi beta, tetapi di versi rilis resmi sudah menghilang
  • Saya selalu penasaran mengapa namanya ILAYER, dan sekarang saya tahu

• Nama fitur ini adalah transklusi (transclusion)
  https://en.wikipedia.org/wiki/Transclusion
  Ini merupakan bagian dari Project Xanadu, dan awalnya dianggap sebagai fitur penting dalam hiperteks. Khususnya MediaWiki memakai transklusi secara luas, dan kadang wiki terasa seperti bentuk hiperteks yang paling murni

  • Ward Cunningham, pembuat Wiki, pernah mencoba membuat wiki yang mengutamakan transklusi, tempat setiap orang memiliki ruang wiki sendiri dan menggunakan transclusion secara sosial
    https://en.wikipedia.org/wiki/Federated_Wiki
    Namun tidak benar-benar populer
  • Menurut saya, transclusion sejati berarti lebih dari itu
    Di Xanadu, hanya sebagian kutipan dari satu dokumen yang bisa ditransclude ke dokumen lain. Untuk melakukan ini di HTML, perlu ada jawaban terkait CSS. Dalam situasi tertentu, bisa diputuskan dan diselesaikan atribut mana yang harus konsisten antara dokumen host, dokumen guest, dan guest yang disematkan di dalam host, tetapi dalam kasus umum ini tidak jelas. Jika memakai pendekatan tag sederhana, dokumen guest harus dirancang agar hidup di dalam lingkungan CSS yang sudah disediakan host. Jawaban sederhana lainnya adalah Shadow DOM, yang pada umumnya memungkinkan guest menerapkan gayanya sendiri tanpa memengaruhi dokumen lainnya. Dalam kasus ini pun, menurut saya host masih bisa memasukkan sebagian style untuk menyesuaikan guest

• Saya rasa inilah yang dulu ingin dilakukan oleh frameset yang sebenarnya. Maksud saya frameset era HTML 4, bukan iframe
  Setidaknya ekspansi ukuran otomatis berjalan baik, dan pengguna juga bisa menyesuaikannya ke ukuran yang diinginkan. Ada banyak kritik terhadap frame [1], tetapi frame berhasil dipakai di tempat-tempat yang berguna seperti dokumentasi Java API [2]. Menurut saya pada akhirnya ia menghilang karena terlalu kurang fleksibel bagi desainer. Untuk halaman informasi memang cukup, tetapi scrollbar yang kaku dan pembagian layar yang terbatas tidak mampu memenuhi kebutuhan desainer. Sekarang frameset apa adanya kemungkinan tidak akan bekerja baik di mobile, jadi sudah terlalu terlambat untuk menghidupkannya kembali
  [1] <https://www.nngroup.com/articles/why-frames-suck-most-of-the...> - Menarik bahwa banyak bagian dari tulisan ini sekarang tidak lagi berlaku, dan semua masalah yang ditunjukkan pada frame kini ada di web masa kini dalam bentuk yang lebih berantakan
  [2] <https://www.eeng.dcu.ie/~ee553/ee402notes/html/figures/JavaD...>

  • Masalah frameset jauh lebih mendasar
    Karena deep link tidak mungkin dilakukan, orang yang masuk lewat bookmark, Google, atau mesin pencari sebelumnya akan mendarat di halaman tanpa navigasi, dan meskipun dicoba diakali dengan JavaScript, itu tidak menghasilkan pengalaman yang baik

• Fitur “include” dianggap sebagai sesuatu yang diproses di sisi server, yaitu di luar browser web
  HTML berada di sisi klien, dan pada dasarnya bukan bahasa pemrograman, melainkan sintaks markup. Seperti yang dikatakan dalam tulisan itu, masalah ini sudah terselesaikan. Hal pertama yang ditemui mahasiswa desain web saat belajar PHP adalah include, dan di kebanyakan CMS, include menjadi template partial yang dijelaskan di bagian awal dokumen. Tidak ada kebutuhan khusus untuk membuat include bisa dilakukan hanya dengan HTML. HTML adalah format presentasi, dan tanpa CSS serta JS ia tidak melakukan hal yang menarik

  • Pernyataan bahwa “include adalah fitur sisi server” bukanlah argumen bahwa include sisi klien tidak boleh ada
    Pada kenyataannya, HTML sudah memiliki versi yang lebih buruk, yaitu frames dan iframes. Padanan sisi klien dari server-side include secara alami cocok dengan hal-hal yang dilakukan orang dengan HTML
  • Alasan terasa aneh adalah karena file HTML dapat menyertakan skrip, font, gambar, video, style, dan sebagainya, tetapi tidak dapat menyertakan HTML
    Mungkin ini bisa dikodekan dengan custom element, dan saya justru akan terkejut jika tidak ada repositori serupa di GitHub
  • Benar bahwa banyak mahasiswa mulai mengenal PHP karena hal ini. Namun tetap saja saya penasaran mengapa cara sederhana berbasis tag tidak bisa dilakukan
    Ada juga konten yang sudah dimuat secara asinkron, seperti gambar atau konten di bagian bawah layar. Pernyataan “HTML bukan bahasa pemrograman melainkan sintaks markup” lebih mirip flamebait, dan HTML adalah bahasa deklaratif yang ditafsirkan oleh tiap engine browser
  • Saya setuju dengan yang dikatakan, tetapi HTML bukan format presentasi, melainkan bahasa deskripsi dokumen
    Jika yang dimaksud adalah styling, presentasi ditangani oleh CSS
  • Pernyataan bahwa “fitur include adalah sisi server” memang benar. Server-side include sepenuhnya alami, tetapi include sisi klien berarti klien harus bisa memodifikasi DOM asli pada waktu yang tidak diketahui klien
    Ada dua pilihan. Pertama, memprosesnya saat parsing HTML, yaitu sebelum DOM dibuat, tetapi ini tidak ideal karena memerlukan request sinkron ke server untuk include. Kedua, setelah DOM dibuat, elemen tertentu muncul di DOM, potongannya dimuat secara asinkron, lalu elemen DOM itu diganti dengan potongan eksternal; namun ini melemahkan mekanisme validasi struktur DOM yang ada. Meski begitu, engine Sciter mengimplementasikannya dengan strategi pertama. HTML Sciter biasanya berasal dari resource aplikasi lokal atau sistem file, sehingga biaya request potongan tambahan dapat diabaikan
    https://docs.sciter.com/docs/HTML/html-include

• HTML include memiliki berbagai masalah seperti yang dikatakan orang lain
  Jika main.html menyertakan child/include1.html, dan di dalam child/include1.html ada tautan src="include2.html", ke mana pengguna harus pergi saat mengkliknya? Jika menuju include2.html, sesuai namanya itu kemungkinan halaman untuk include sehingga bagian lainnya hilang; jika menuju main.html, bagaimana menentukan bahwa kali ini yang harus dipakai adalah include2.html, bukan include1.html? Sebaliknya, article1.html, article2.html, article3.html masing-masing bisa dibuat menyertakan header.html, footer.html, navi.html, tetapi jika begitu, untuk mengubah struktur semua artikel secara global, semua artikel harus dimodifikasi. Jika ingin menambahkan comments.html ke semua artikel, pada akhirnya Anda ingin membuat halaman lagi dengan template, dan pada titik itu browser include tidak lagi diperlukan. Masalah lain juga muncul, seperti header perlu mengetahui judul atau footer perlu mengetahui tautan sebelumnya/berikutnya; dibutuhkan cara untuk saling mengirim informasi antar-include, dan akhirnya kembali lagi ke pembuatan halaman. Jika dipikirkan, HTML include kemungkinan besar praktis tidak berguna untuk sebagian besar penggunaan

  • Masalah-masalah seperti ini semuanya bisa diselesaikan, dengan solusi yang cukup jelas
    Di sini ada dua use case berbeda yang tercampur. Yang satu adalah penggunaan ulang potongan, dan yang lain adalah pulau mandiri yang dapat di-embed. Yang terakhir sudah ditangani oleh iframe, jadi yang perlu diselesaikan hanya yang pertama
  • Logika bahwa include2.html kehilangan bagian lainnya juga berlaku sama untuk include lain
    Jika pengguna mengklik tautan src="include.css", hasilnya akan kacau. Untuk data statis, gambar, CSS, dan konten HTML statis, ini mungkin baik-baik saja

• Ada isu terbuka terkait hal ini di WHATWG. Ini juga disebutkan di bagian komentar artikel blog
  Client side include feature for HTML
  https://github.com/whatwg/html/issues/2791

• HTML pernah memiliki include, lalu popularitasnya hilang
  Istilah “include” yang sebenarnya adalah fitur XML, dan itulah yang diinginkan tulisan tersebut. HTML punya pendekatan lain yang muncul sebelum XML, yaitu frames. Karena frames melakukan jauh lebih banyak hal daripada XML include, HTML tidak mendapatkan fitur itu secara terpisah. Frames kehilangan popularitas karena berbagai masalah seperti penyalahgunaan, keamanan, dan aksesibilitas

  • Berbeda dengan frameset, XML include tampaknya tidak pernah benar-benar didukung dengan baik oleh banyak browser, atau mungkin oleh browser besar mana pun
    Saya masih suka menggunakannya sesekali, tetapi diperlukan tahap kompilasi yang mengevaluasinya sebelum diserahkan ke pengguna atau browser