Mengapa elemen `html` tidak didukung 100% di caniuse.com

 (anderegg.ca)
2 poin oleh GN⁺ 2024-02-03 | 1 komentar | Bagikan ke WhatsApp
  • CanIUse.com adalah situs yang melacak kompatibilitas teknologi web, tetapi tingkat dukungan untuk elemen dasar html ditampilkan sebagai 97.34%, sehingga memunculkan pertanyaan tentang cara menafsirkan angka tersebut
  • Tingkat dukungan ini tampaknya terhubung dengan data kompatibilitas MDN yang digunakan CanIUse.com, dan beberapa subitem pada halaman elemen html tampaknya memengaruhi hasilnya
  • Item yang dipermasalahkan adalah atribut manifest yang opsional dan secure context required, yang keduanya tidak pernah distandardisasi atau sudah ditinggalkan
  • Karena penanganan browser yang tidak didukung/tidak jelas status dukungannya bercampur dengan browser lama, tingkat dukungan untuk elemen dasar seperti html pun bisa tampil tidak sesuai intuisi
  • Pada dasar perhitungan “% of all tracked”, jika support unknown ikut ditambahkan maka angkanya bisa dilihat sebagai 99.98%, sehingga kemungkinan galat pembulatan menjadi lebih besar, tetapi angka di CanIUse.com tetap perlu dibaca dengan lebih hati-hati

Pertanyaan yang muncul dari tingkat dukungan html 97.34%

  • CanIUse.com melacak tingkat adopsi browser dan kompatibilitas fitur untuk teknologi web, lalu menampilkan angka yang menunjukkan seberapa jauh fitur tersebut benar-benar bisa digunakan
  • Tingkat dukungan elemen html ditampilkan sebagai 97.34%
    • Ini lebih rendah daripada elemen audio
    • Elemen a dan p juga ditampilkan dengan tingkat dukungan 97.34% yang sama
  • Karena elemen-elemen dasar web yang telah digunakan sejak lama ternyata tidak mencapai 100%, perlu pemeriksaan lebih lanjut, bukan sekadar melihat angka kompatibilitas mentah

Subitem yang terlihat di tabel kompatibilitas MDN

  • Banyak data di CanIUse.com tampaknya diambil dari MDN
  • Pada halaman elemen html di MDN terdapat bagian kompatibilitas browser
  • Di tabel ini, ada dua item yang memiliki banyak tanda X merah
  • Memang benar hampir semua browser tidak mendukung dua item ini, tetapi itu saja belum cukup menjelaskan mengapa tingkat dukungan keseluruhan elemen html turun hingga 97.34%

Kemungkinan browser lama dan galat pembulatan

  • Beberapa browser ditandai sebagai Support Unknown, dan total pangsa penggunaan saat ini untuk browser-browser ini adalah 1.27%
  • Android Browser 2.1–4.3 ditandai tidak mendukung elemen html, tetapi pangsa penggunaannya adalah 0%
    • Klaim bahwa browser lama ini benar-benar tidak mendukung elemen html terasa meragukan
    • Juga tidak jelas apakah galat pembulatan bisa membesarkan 1.27% menjadi 2.66%
  • Jika di kanan atas CanIUse.com, dasar perhitungan di samping “usage” diubah menjadi “% of all tracked” lalu angka browser “support unknown” ikut ditambahkan, hasilnya menjadi 99.98%
    • Dengan dasar ini, lebih mudah melihat kemungkinan bahwa angka saat ini muncul karena galat pembulatan
    • Meski begitu, cara CanIUse.com menangani browser lama untuk elemen dasar seperti html tetap terasa membingungkan
  • CanIUse.com tetap merupakan sumber yang berguna, tetapi angka dukungan yang ditampilkan perlu dibaca sambil memeriksa konteks dan dasar perhitungannya

Bacaan terkait

1 komentar

 
GN⁺ 2024-02-03
Pendapat di Hacker News

  • Di CanIUse ada opsi "% of all" tepat di atas persentase Global. Jika membuka ikon roda gigi di halaman fitur, cara perhitungan penggunaan dijelaskan lebih rinci. Nilai bawaannya adalah All Users, yang menganggap semua penggunaan browser yang tidak dilacak oleh caniuse sebagai tidak didukung. Jika diubah ke All tracked users, hanya browser yang dilacak yang dihitung, sehingga hasilnya menjadi 98,71%. Jumlah browser yang status dukungannya Unknown di grafik adalah 1,27%; jika 1,27% ditambahkan ke 98,71%, hasilnya 99,97999…, jadi tampaknya ada pengaruh pembulatan. Masalah sebenarnya adalah browser-browser itu ditampilkan sebagai Unknown, dan dalam praktiknya sepertinya boleh dianggap mendukung elemen ``.

    • Melihat string User-Agent yang “tidak terlalu jelas teridentifikasi” di log request API SaaS kami, tampaknya cukup banyak dari 1,27% “browser” itu kemungkinan adalah berbagai scraper tujuan khusus yang kebetulan masuk di luar ranah spesialisasinya. Jadi belum tentu mereka bisa mem-parse ``. Bisa saja itu scraper JSON.
    • Saya banyak memakai wget; kalau itu ikut dihitung, ceritanya berbeda. Setelah mengecek src/html-url.c, ternyata sebenarnya sama sekali tidak mendukung `` dan memperlakukannya sebagai tag tak dikenal.

  • Saya sempat penasaran bahwa MDN dulu merupakan singkatan dari Mozilla Developer Network tetapi sekarang hanya MDN, lalu mencoba mencarinya, namun saya juga tidak bisa menemukan nama lengkapnya.

    • Perubahan itu terjadi sekitar 2017. Nama Mozilla Developer Network agak ambigu, dan survei serta wawancara pengguna juga menunjukkan kebingungan. Para pengembang web mengira itu adalah materi khusus untuk pengembang Mozilla; pada masa awalnya memang sifatnya cukup kuat seperti itu, jadi tidak sepenuhnya salah. Untuk beberapa waktu, selain dokumentasi platform web, MDN juga memuat banyak dokumentasi terkait Mozilla. Namun pada 2017, dokumentasi platform web sudah menyumbang 95% trafik MDN, dan materi untuk pengembang Mozilla bukan lagi identitas utamanya. Karena itu namanya diubah menjadi MDN Web Docs agar perubahan fokus tersebut terlihat.
    • Perubahan ini terjadi sekitar 15 Agustus 2017. Saya tahu karena kebetulan melihat momen ketika branding sudah berubah tetapi isi halaman belum berubah. Laporan bug yang saya ajukan saat itu ada di sini: https://bugzilla.mozilla.org/show_bug.cgi?id=1390381
    • Saya suka menyebut hal seperti ini anachronym. Rasanya seperti singkatan yang anakronistis. Secara ketat, ini lebih merupakan initialism daripada akronim, tetapi saya juga pernah menulis artikel terkait. https://simpsonian.ca/blog/anachronyms/
    • Memang masih tersisa di beberapa halaman samping dan kode contoh, tetapi yang saya temukan hanya sejauh ini: “will soon be a proud part of the Mozilla Developer Network (MDN)” — https://developer.mozilla.org/en-US/blog/mdn-observatory/ “Their brilliant but offbeat idea grew into today's Mozilla Developer Network” — https://developer.mozilla.org/en-US/docs/MDN/At_ten const heading = Mozilla Developer Network; — https://developer.mozilla.org/en-US/docs/Learn/Tools_and_tes...
    • Saya ingat beberapa tahun lalu dokumentasi Microsoft mulai merujuk ke dokumentasi Mozilla. Mungkin itu bagian dari rebranding Edge. Kalau nama MDN diubah dalam proses kesepakatan itu, bisa jadi tujuannya menghindari kebingungan seperti “ini M(ozilla)DN atau M(icrosoft)DN?”, tetapi saya tidak tahu pasti.

  • Menariknya, saya mendengar bahwa elemen dan juga menunjukkan tingkat dukungan 97,34% yang persis sama. Kedua elemen ini juga memakai data dari MDN seperti elemen ``: https://caniuse.com/mdn-html_elements_a dan https://caniuse.com/mdn-html_elements_p Saya sudah memperbarui tulisan untuk mencerminkan hal ini.

  • Sepertinya CanIUse boleh saja memisahkan html-manifest sebagai fitur tersendiri. Dan saya juga ingin menegaskan lagi bahwa MDN benar-benar sumber yang luar biasa.

  • Halaman web pertama tidak memakai elemen html. http://info.cern.ch/hypertext/WWW/TheProject.html

  • Apakah ini ada hubungannya dengan HTML valid minimal? Di sana tidak ada tag HTML.

    • Sepertinya tidak terlalu berkaitan. `` juga muncul dengan persentase yang hampir sama: https://caniuse.com/mdn-html_elements_title Ini tampaknya lebih merupakan masalah bagaimana menghitung browser yang penggunaannya diketahui tetapi status dukungannya belum bisa diverifikasi. Tambahan lagi, HTML itu sebenarnya tidak valid dan diperlakukan sebagai judul kosong, sedangkan judul kosong tidak valid. Jika diubah menjadi sesuatu seperti ., seharusnya lolos tanpa error.
    • Tapi bukankah di sana ada tag ? Hanya saja tidak dinyatakan secara eksplisit, sehingga diinferensikan. Dibuka dengan browser apa pun, halaman itu akan memiliki tag .
    • Di dalam protokol yang bisa menyampaikan judul dengan cara lain, seperti header Subject pada email, bersifat opsional. Jadi HTML valid terpendek hanyalah satu saja, tetapi itu hanya valid dalam konteks tertentu.

  • Pernyataan bahwa “banyak data situs berasal dari MDN” agak ambigu. Matriks dukungan fitur yang terhubung ke CanIUse berasal dari repositori browser-compat-data milik MDN. Data sumber untuk elemen HTML ada di sini: https://github.com/mdn/browser-compat-data/blob/main/html/el... Namun di sana tidak ada pengujian dan informasi penggunaan yang dikutip CanIUse untuk menghitung tingkat dukungan; hanya ada versi browser mana yang menyertakan fitur tertentu. CanIUse juga menunjuk ke repositorinya sendiri, dan di sana ada banyak data: https://github.com/fyrd/caniuse Namun saya tidak menemukan titik masuk yang memudahkan untuk mengetahui dari mana angka untuk elemen tertentu berasal. Data di sana juga tampaknya terutama berbasis fitur. Pertanyaan yang lebih tepat adalah dari mana CanIUse mengambil pengujian elemen HTML dan angka penggunaan, dan itu tampaknya merupakan inti masalahnya.

  • Bukankah tingkat dukungan elemen `` setidaknya harus lebih rendah atau sama dibanding elemen lain mana pun?

    • Tidak. Elemen bukan berarti “seluruh HTML”; itu hanyalah satu elemen lain yang berarti **elemen root dokumen**. Seperti yang ditulis orang lain, elemen itu sebenarnya juga tidak wajib untuk membuat dokumen HTML valid tanpa error; yang diperlukan saat itu adalah dan isi body yang valid. Sebagai analogi, kemampuan memahami dan mem-parse kata “English” dalam judul esai terpisah dari mengetahui arti kata bahasa Inggris “fustigate”.

  • “Jadi tidak ada jawaban yang jelas. Kalau ada yang tahu, beri tahu!”