Usulan penghapusan penyebutan XSLT dari spesifikasi HTML

 (github.com/whatwg)
2 poin oleh GN⁺ 2025-08-20 | 1 komentar | Bagikan ke WhatsApp
  • Sebuah Pull Request telah diajukan untuk menghapus penyebutan terkait XSLT dari dokumen standar HTML
  • Pengusul menjelaskan bahwa bug implementasi terkait telah dilaporkan di peramban utama seperti Chrome, Firefox, dan Safari, serta isu pengujian dan dokumentasi juga sedang ditangani
  • Pendapat yang menolak menyoroti masalah kompatibilitas situs web yang sudah ada dan masalah keterbacaan yang membuat dokumen XML rusak bila <?xml-stylesheet?> dihapus
  • Beberapa pengembang menekankan bahwa XSLT masih digunakan untuk dokumen pemerintah, RSS, dan lingkungan tertanam
  • Muncul kekhawatiran bahwa keputusan yang berpusat pada vendor peramban besar dapat mengarah pada penyusutan keterbukaan web dan keberagaman historisnya

Ringkasan Pull Request

  • Judul PR: Remove mentions of XSLT from the html spec
  • Pengusul: mfreed7
  • Target: whatwg/html:main
  • Isu terkait: #11523
  • Terdapat laporan bug implementasi terkait di Chromium, Gecko, dan WebKit
  • Materi terkait seperti dokumentasi MDN dan HTML AAM dijadwalkan untuk diperbarui

Argumen penolakan utama

gucci-on-fleek (2025-08-15)

  • Menyatakan bahwa statistik penggunaan dan skala situs web harus dipertimbangkan
    • Situs besar mungkin bisa diperbarui, tetapi situs kecil/pribadi sering tidak dipelihara selama puluhan tahun, sehingga ada kekhawatiran kerusakan kompatibilitas permanen
  • Menghapus XSLTProcessor() hanya membatasi fitur JS, tetapi menghapus <?xml-stylesheet?> menyebabkan dokumen XML tidak dapat ditampilkan sama sekali
  • Fitur HTML lama (<font>, <align>, <xmp>) masih tetap berfungsi, tetapi kali ini perubahan tersebut dianggap belum pernah terjadi sebelumnya karena merusak dokumen itu sendiri
  • Ditekankan adanya risiko bahwa akses ke materi penting seperti arsip lama dan situs universitas dapat terputus

nomis (2025-08-18)

  • Memberikan contoh penggunaan konkret XSLT
  • Kasus penggunaan pribadi
    • Mengubah data XML kompleks menjadi tabel HTML
    • Mengubah XML dinamis menjadi XSLT statis pada mikrokontroler dengan keterbatasan memori
  • Mengkritik bahwa polyfill JS yang memuat libxml2 secara penuh tidak realistis, dan penghapusan dukungan peramban pada praktiknya memaksa implementasi ulang

jonsterling (2025-08-18)

  • Mengkritik kenyataan bahwa vendor peramban secara eksklusif mendefinisikan platform web
  • Menyatakan bahwa XSLT masih berkontribusi pada beragam dan kreatifnya pemanfaatan web, dan penghapusannya dapat melemahkan Open Web
  • Menekankan prinsip bahwa "web adalah milik kita semua" dan perlunya menghormati sejarah serta keberagaman

Dukungan dan tindak lanjut

  • domenic (2025-08-19): Menunjukkan respons positif dan menyoroti perlunya memperbarui penyebutan XSLT di spesifikasi DOM juga
  • mfreed7 (2025-08-19): Menjawab bahwa ia akan mengajukan PR terpisah untuk spesifikasi DOM juga

Ringkasan

  • Penghapusan XSLT diusulkan sebagai bagian dari upaya menyederhanakan dan memodernisasi peramban
  • Namun, pihak yang menolak mengkhawatirkan rusaknya kompatibilitas dokumen yang sudah ada, aksesibilitas data pemerintah/akademik, dan keberagaman web terbuka
  • Diskusi ini berkembang melampaui pilihan teknis semata, hingga menjadi perdebatan filosofis tentang siapa yang memiliki kewenangan dalam menentukan standar web

Bacaan terkait

1 komentar

 
GN⁺ 2025-08-20
Komentar Hacker News

  • Ada beberapa hal yang patut diperhatikan

    • Keputusan kali ini bukan tindakan sepihak Chrome saja, dan dari pelacakan isu serta catatan rapat standar terkait dapat dipastikan bahwa perwakilan dari semua browser utama menyatakan dukungan

    • Agenda terbaru ini juga diajukan oleh seorang insinyur Mozilla

    • Pengajuan PR tidak berarti langsung di-merge, dan masih ada cukup banyak tugas yang belum dicentang

    • Namun, karena beberapa vendor browser sudah sepakat, kemungkinan besar PR ini akan di-merge

    • Isu yang mempertimbangkan apakah XSLT akan dihapus dari platform web bukan untuk menjaring pendapat komunitas, melainkan isu diskusi bagi para pemelihara spesifikasi HTML

    • Isu ini diajukan oleh insinyur Chrome, tetapi yang penting adalah insinyur Mozilla sudah beberapa kali mengangkat topik ini dalam rapat dan kesepakatan antvendor sebenarnya sudah ada

    • Pernah ditemukan kerentanan keamanan yang serius

    • Maintainer utama libxslt juga mundur langsung

    • Kata Chrome sudah dihapus dari judul

    • Judul yang semula diajukan adalah "Chrome intends to remove XSLT from the HTML spec"

    • Menurut data telemetri Chrome, hampir tidak ada situs web yang benar-benar menggunakan XSLT

    • Setidaknya data menunjukkan bahwa usulan ini tidak memberi dampak besar pada web secara keseluruhan

    • Saya adalah pengembang yang dulu pernah bekerja di Mozilla dan Google (tim Chrome)

    • Saya paham bahwa Chrome/Blink, Safari/Webkit, dan Firefox/Gecko semuanya mendukung penghapusan XSLT, tetapi dua proyek kekurangan sumber daya, dan satu pihak sangat cenderung memaksakan fitur baru

    • Ada alasan mengapa pengembang Safari dan Firefox mungkin menyambut perubahan seperti ini

    • Yang penting bukan apakah 'orang-orang berotoritas menganggap ini ide bagus', melainkan 'apakah ide ini akan berdampak negatif pada platform web dan miliaran pengguna'

    • Kalau hanya 0,1% dari miliaran orang yang bergantung padanya pun, skalanya tetap besar

    • Kalau memang tidak ada yang memakainya, tidak ada alasan polyfill itu ada

    • Jika ingin menambahkan fitur baru, tidak baik mendorongnya menjadi permainan zero-sum yang mewajibkan penghapusan fitur lama

    • Google memilih untuk sengaja tidak mendukung XSLT meski punya modal dan tenaga kerja yang cukup

    • Sering ada kasus ketika beberapa vendor setuju lalu dorongan implementasi langsung berjalan

    • Penghapusan confirm/prompt juga begitu, tetapi pada akhirnya ditunda tanpa batas waktu

    • Ada dokumen proses resmi penghapusan fitur yang berafiliasi dengan Google
      Google feature removal doc

    • "Dukungan vendor semata" tidak benar-benar meninjau kondisi penggunaan nyata

  • Dari dua thread yang saya baca, Google meminta masukan, tetapi hampir semua masukannya adalah "jangan lakukan"

    • Namun respons Google pada dasarnya adalah, "terima kasih atas masukannya, tapi kami tetap akan melakukannya!"

    • Jika isu ini soal keamanan, sebenarnya ada banyak alternatif seperti mendukung proyek open source, mengganti dengan library yang lebih aman, atau mempertahankannya di dalam sandbox JS, tetapi sebagian besar diabaikan

    • Permintaan dukungan untuk versi terbaru seperti XSLT 3.0 juga terus ada, tetapi tidak direspons

    • Walaupun XSLT adalah teknologi yang mendukung web terbuka, Google sudah mengurangi dukungan dan menelantarkannya sejak 10 tahun lalu, lalu terus mencoba menghapusnya dengan alasan pangsa penggunaannya turun

    • Di saat XSLT mulai populer lagi belakangan ini, terasa ada niat untuk mematikannya sebelum pesaing terbuka muncul

    • Isu terkait

    • Menanggapi klaim bahwa banyak masukan berbunyi "jangan lakukan", thread tersebut dikunci lebih awal karena komentar bernada buruk, hinaan, dan semacamnya

    • Komentar seperti "ini ide bagus" biasanya memang tidak banyak ditulis, sehingga bisa tampak seolah hanya ada pendapat yang menentang

    • Semua orang bersikap terlalu ekstrem sehingga diskusinya dibereskan, dan itu akibat ulah mereka sendiri

    • Jika komentar "jangan lakukan" itu bukan dari pengguna nyata atau tidak bisa menjelaskan alasan mengapa hal itu benar-benar perlu, masuk akal jika tim pengembang mengabaikannya

    • Permintaan masukan bukan sekadar pemungutan suara setuju/tidak setuju

    • Akan bagus jika XSLT 3.0 bisa didukung dengan dipindahkan ke sandbox JS/wasm

    • Mungkin ada sedikit penurunan performa, tetapi kedua sisi keuntungannya bisa didapat

    • XML relatif mudah diintegrasikan berkat karakteristik seperti skema versioning dan namespace

    • Berbeda dengan framework js seperti Angular, XML memungkinkan kontrak data yang andal

    • Berkat kematangan keluarga XML, ada banyak alat profesional, sehingga pada praktiknya kita tidak perlu menangani XML/XSD secara langsung sebagai teks

    • Google memberi tahu apa yang akan terjadi di web lebih dulu dengan bentuk "pertanyaan"

  • Pengenalan thread terkait sebelumnya

  • Saya ragu browser perlu memiliki dukungan bawaan untuk mesin templating tertentu seperti XSLT

    • Ini bukan mesin teks seperti Jinja, jadi tetap bisa diimplementasikan ulang dengan JS/wasm

    • Browser sekarang terlalu berat, dan membuat mesin baru itu sulit

    • Saya berharap ada standar yang lebih sederhana untuk "browser minimal" saja, seperti tag dasar dan layout

    • WebAudio, Canvas, dan sebagainya juga bisa diimplementasikan sebagai modul wasm (dan dengan begitu fingerprinting juga bisa dicegah)

    • XSLT adalah "spesifikasi" untuk mesin templating, bukan mesin tertentu, dan ada berbagai implementasi

    • Mozilla memakai transformiix alih-alih libxslt

    • Jinja hanya bekerja pada teks sederhana, sedangkan XSLT bekerja di level node sehingga jauh lebih unggul

    • Transformasi dengan JS jauh lebih lambat daripada transformasi XSLT native, dan caching hasilnya juga lebih sulit

    • Saya paham pandangan yang menganggap XSLT kuno, tetapi selama 20 tahun terakhir saya memakainya sebagai senjata rahasia dari sisi performa

    • Pada akhirnya Google kemungkinan besar akan mencoba menutupi masalah ini dengan alternatif seperti AMP

    • Browser menjadi berat itu salah Google

    • XSLT adalah bahasa (spec), bukan mesin

    • Mengubah implementasi ke JS/wasm adalah persoalan implementasi internal, bukan hal yang terjadi saat bahasanya dihapus dari platform web

    • Audio atau canvas adalah fungsi I/O mendasar browser, jadi memindahkannya ke wasm akan menimbulkan masalah performa dan kompatibilitas yang serius

    • Sebagian audio mungkin bisa dipindahkan ke blob wasm, tetapi memindahkan semuanya akan sulit

    • Canvas context, WebGL, dan sejenisnya bertumpu pada integrasi langsung dengan GPU, jadi tidak mungkin diwujudkan lewat wasm

    • Pada akhirnya fitur-fitur seperti ini pada dasarnya sudah merupakan API primitif, jadi itu wilayah yang tidak bisa dikorbankan

    • Ada juga diskusi tentang ide mengemas kode XSLT lama ke dalam wasm agar situs lama tidak rusak

    • Bahkan itu sempat dipertimbangkan secara internal, tetapi akhirnya diputuskan untuk tidak dilakukan

    • Saya pikir fitur yang sangat jarang dipakai dan jauh dari kebutuhan web bisa saja menjadi target penghapusan

    • Tetapi saya tidak setuju jika kerentanan keamanan dijadikan dalih

    • Tanpa memastikan dulu apakah ada paket memory-safe, argumennya kurang meyakinkan

    • Ada klaim bahwa tingkat penggunaan nyatanya berada di kisaran 0,001%

  • Melanggar janji dasar spesifikasi HTML adalah hal yang sangat serius

    • Justru mengejutkan bahwa diskusinya tidak membahas poin ini secara mendalam

    • HTML dulu adalah janji bahwa "ini HTML. Anda bisa mempercayainya", tetapi sekarang menjadi "ini HTML untuk saat ini saja, tidak ada jaminan akan tetap begitu di masa depan"

    • Jika logika penghapusan XSLT diterima, teknologi lama lain juga bisa terus dipangkas

    • Pada akhirnya ini adalah usulan untuk memotong 'ekor panjang' web

    • Perlu juga dipikirkan bahwa berbagai teknologi web yang ditambahkan ke depan bisa menjadi ekor panjang baru dan melahirkan lebih banyak target penghapusan

    • Soal dukungan untuk media dan perangkat lunak lama, saya rasa pada akhirnya akan datang waktunya untuk menyelesaikannya lewat porting, emulasi, arsip, dan sebagainya

    • Diperlukan keseimbangan antara memberi waktu dan alat yang cukup untuk bersiap menghadapi perubahan, serta menghindari akumulasi kompleksitas secara bertahap

    • Jika melihat bagian yang dihapus pada PR sebenarnya, tampaknya tidak ada aturan eksplisit yang mewajibkan dukungan XSLT di HTML

    • Reaksinya tampaknya lebih besar sebagai soal dukungan browser

    • PR-nya sendiri ternyata cukup pendek

    • Dengan WHATWG mendefinisikan HTML sebagai "Living Standard", secara praktis ini bukan lagi standar implementasi, melainkan sarana bagi vendor browser untuk berbagi status pekerjaan yang sedang berlangsung

    • Karena itu penandaan versi seperti HTML5 juga dihapus, dan hanya "HTML" yang dipakai

    • Living Standard FAQ

    • HTML standard FAQ

    • Ironisnya, salah satu pihak yang paling banyak mendorong masuknya fitur ke dalam spesifikasi HTML/CSS/browser justru Google

    • Jika Google secara konsisten membela gagasan bahwa "browser harus ringan dan hal-hal aneh sebaiknya diserahkan ke library JS", mungkin langkah kali ini masih bisa dimengerti, tetapi kenyataannya sama sekali tidak begitu

  • Sejak penghapusan dukungan FTP, nasib XSL sebenarnya sudah bisa ditebak

    • Browser cenderung menempatkan pengurangan attack surface sebagai prioritas tertinggi

    • Saya merasa kandidat penghapusan berikutnya mungkin adalah atribut animasi SVG SMIL, MathML, dan fitur terkait XML lainnya

    • Thread terkait

    • SMIL bisa mengendalikan animasi berurutan berdasarkan waktu mulai/selesai animasi tertentu, sedangkan animasi CSS masih kurang di bagian ini

    • CSS tidak punya banyak cara selain menggunakan timing berbasis perhitungan

    • Chromium juga pernah menyatakan niat menghapus SMIL, tetapi saat itu CSS belum cukup, jadi langkah itu terlalu terburu-buru

    • Dampaknya, berbagai panduan terkait SMIL dibiarkan terbengkalai tanpa pembaruan

    • Saya ingin mempertanyakan apakah mengurangi attack surface itu benar-benar hal yang baik atau buruk

    • Prioritas teknisi dan pengguna umum memang berbeda

    • Saya penasaran kapan penghapusan fitur FTP dilakukan

    • Setahu saya masih bisa mengakses ftp:// dari bilah alamat

  • Implementasi XSLT di Blink dan WebKit sangat tidak efisien

  • Saya menyesalkan keputusan ini, tetapi lebih disayangkan lagi bahwa tidak ada upaya untuk mendorong integrasi XSLT yang lebih modern

    • Memang pemakaiannya tidak nyaman, tetapi jika browser sedikit lebih berkembang, ini mungkin bisa menjadi pesaing sekelas framework seperti React

    • XML, jika terlepas dari kompleksitas ala perusahaan besar, sebenarnya adalah standar yang sangat kuat dan teknologi yang keren

    • Saya sangat suka bisa langsung mengubah xml/data kecil dan sederhana menjadi html dengan XSLT

    • Sangat disayangkan, kalau saja ada sedikit fitur tambahan untuk menampilkan item terpilih secara berbeda, mungkin ini bisa dipakai lebih luas bahkan untuk dokumen statis

  • @whatwg dikabarkan mengunci isu tersebut hanya untuk kolaborator dengan alasan diskusinya "terlalu panas"

    • Dari luar tampak cukup masuk akal dan tenang, jadi terasa seperti standar tentang apa yang dianggap 'terlalu panas' bisa berubah tergantung apakah seseorang berpihak pada vendor tertentu

    • Ungkapan "terlalu panas" sering ditafsirkan sebagai tidak ingin menghadapi pendapat yang berlawanan

    • Komunitas lain seperti Reddit juga begitu

    • Bahkan satu-satunya komentar yang tersisa di bawahnya adalah dari pengembang Google Chrome yang menulis "kerja bagus"

    • Agak memalukan untuk dilihat

    • Disebutkan ada kasus umpatan provokatif, teori konspirasi, pesan politik, dan sejenisnya membanjiri issue tracker

    • Dalam situasi seperti itu, diskusi produktif memang menjadi mustahil dan para pengelola repositori tidak punya pilihan selain cepat menghentikan diskusi

    • Saya dengar tindakan penguncian diskusi di repositori itu sebenarnya dilakukan oleh karyawan Apple

    • Tetapi orang-orang justru menyalahkan karyawan Google yang mengangkat isu ini

    • Belakangan Google mengadakan diskusi terbuka atas nama menjaring masukan komunitas, tetapi setelah itu tampaknya ingin mengabaikan semua pendapat dan tetap memaksakannya

    • Isu terkait

  • Perlu ada pemikiran yang lebih luas tentang elemen-elemen web lama

    • Dalam kasus saya, ada nilai besar dari tetap berfungsinya halaman web lama dengan baik

    • Berkat kompatibilitas HTML/JS yang terus dijaga, bahkan halaman berumur puluhan tahun tetap berjalan normal selama diberi sertifikat TLS

    • Namun, tidak mungkin semua teknologi warisan didukung selamanya

    • Flash pada akhirnya juga bergeser ke pengalaman nostalgia game atau situs lama lewat emulator (Ruffle)

    • Dalam jangka panjang, memakai browser khusus atau emulator yang dioptimalkan untuk rendering lama juga bisa menjadi alternatif

    • Sudah ada ekstensi polyfill XSLT untuk tujuan ini

    • Chrome tidak ingin mengirimkan atau memelihara ini secara resmi

    • Situasinya sangat mirip dengan Ruffle