Kategori
Web Standards

XHTML5 Poliglot plus SVG dan MathML

Diperbarui 19 November 2012 oleh Dani Iswara

Dalam hal ini, dokumen polyglot bisa menyajikan HTML dengan markah/sintaks XHTML. XHTML5 memungkinkan hal ini.[1] Menurut KBBI daring, poliglot didefinisikan seperti di bawah,

po·li·glot 1 a dapat mengetahui, menggunakan, dan menulis dalam banyak bahasa; 2 n orang yang pandai dalam pelbagai bahasa.

Seperti 'dokumen bunglon'. Tergantung kecerdasan peramban Web memahaminya.

Menurut Sergey Mavrody, dokumen XHTML5 memiliki ciri berikut.[2] Ditulis dalam bahasa saya, disertai pengembangan.

  • Deklarasi <!DOCTYPE html> (dengan 'DOCTYPE' memakai huruf besar; string 'html' dengan huruf kecil) tidak wajib dipakai. Tetapi bermanfaat untuk menghindari quirks mode di sisi peramban Web. Dalam quirks mode, halaman Web mungkin hanya tersaji sebagai plaintext biasa. Biasanya terjadi di peramban Web lawas.
  • Penulisan sintaks/markah XHTML yang sangat baik dan ketat. Saking ketatnya, kesalahan penulisan markah akan menyebabkan halaman tidak tersaji sempurna hingga menimbulkan death screen. Tapi ternyata, saya menemukan halaman galat itu masih bisa terindeks oleh mesin telusur/pencari.
  • Memiliki tipe dokumen application/xhtml+xml. Tidak tampak di kode sumber. Dimengerti sebagai HTTP Content-Type header yang bisa dikonfigurasi di sisi server. Walau 'bisa' menampilkan dokumen XHTML, peramban Internet Explorer (MSIE) masih belum bisa membaca berkas XML dengan baik. Sehingga, dari percobaan saya memakai SVG dan MathML, MSIE butuh plugin untuk membacanya.
  • Namespace XHTML standar memakai <html xmlns="http://www.w3.org/1999/xhtml">.
  • Namespace kedua seperti SVG, MathML, Xlink, dan lainnya, bagi Sergey, hanya berupa tes saja. Masih menurut Sergey, jika kita tidak membutuhkan fitur tambahan itu, pemakaian XHTML is overkill in the first place. Saya setuju.

Jika HTML5 ditulis dengan markah HTML dan disajikan sebagai text/html, ini disebut serialisasi HTML.
Jika HTML5 ditulis dengan markah XML dan disajikan sebagai application/xhtml+xml, ini disebut XML atau XHTML.

Contoh struktur standar XHTML5:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Contoh XHTML5 + SVG + MathML</title>
<meta charset="UTF-8" />
</head>
<body>
<section>
<article>
<header><h1>Penerapan SVG dan MathML <em>inline</em></h1></header>
<p>Konten di sini...</p>
</article>
</section>
<footer>Copyleft 2010 Dani Iswara</footer>
</body>
</html>

Mengganti doctype saja tanpa memakai elemen khas HTML5 seperti header, section, article, footer, bukanlah HTML5.

Lihat (Dani Iswara .com):

  • Contoh XHTML5+SVG+MathML (.xhtml).
  • HTML5+SVG+MathML (.html). SVG dan MathML tidak tersaji dengan baik.
  • HTML5+SVG+MathML (.xhtml). Death screen tersaji karena memaksakan memakai deklarasi doctype dengan huruf kecil untuk ekstensi .xhtml. Contoh pesan galat markah di Firefox:

    XML Parsing Error: syntax error
    Location: https://daniiswara.com/sample/html5-svg-mathml.xhtml
    Line Number 1, Column 1:

    <!doctype html>

    Pesan galat di Opera lebih bersahabat.

Bisa divalidasi dengan fitur percobaan validator HTML5 dari Validator.nu.[3] Coba juga perkakas TotalValidator.com (ada pengaya Firefox-nya).

Aksesibilitas & kebergunaan XHTML

Deklarasi UTF-8 sebagai standar encoding lebih dianjurkan. Jika memakai encoding selain UTF-8 dan UTF-16, deklarasi XML harus disertakan. Untuk dokumen poliglot, pakai juga tag <meta charset=''UTF-8'' /> di <head>. Biasanya, dokumen XML murni akan disajikan dengan mencantumkan deklarasi <?xml version="1.0" encoding="utf-8"?> di bagian paling awal/atas dokumen. Dan memakai ekstensi .xhtml atau .xml untuk tiap berkasnya. Sehingga halaman akan tersaji sebagai application/xhtml+xml. Lebih disarankan memakai pengaturan di sisi server untuk deklarasi UTF-8.

Tapi nyatanya, pengguna dan penyaji konten Web kebanyakan memakai dokumen text/html. Walaupun menuliskan tipe dokumen XHTML 1.0 Transitional, Strict, atau XHTML 1.1 di kode sumbernya. Artinya, di mata peramban Web, dokumen tersebut sama saja dengan HTML. Sehingga sejak versi 0.83, Validator (X)HTML W3C akhirnya mengubah kebijakannya dan mengizinkan dokumen XHTML disajikan sebagai text/html untuk memuaskan pengguna yang peduli validasi.[4]

Jika tidak menyajikan konten yang membutuhkan serialisasi, modularisasi, atau fitur tambahan/tempelan seperti SVG dan MathML, maka HTML adalah pilihan yang logis.

Beruntunglah kita, HTML5 akan mengakomodasi bahwa fitur tambahan itu jadi lebih mudah dipasang di dokumen HTML. Tinggal menanti dukungan para peramban Web.

Manfaat SVG & MathML sudah sempat saya tulis sebelumnya. Silakan telusuri tag dan kategori terkait di Dani Iswara .com & Dani Iswara .Net. SVG & MathML tersaji sebagai konten. Dengan atau tanpa bantuan CSS. Bisa pula dibuat interaktif dengan bantuan skrip tertentu.

Sayangnya, tidak/belum semua peramban Web mampu membacanya dengan baik. Masalah inkompatibilitas dan kesesuaian standar masih jadi pekerjaan rumah hingga saat ini. Termasuk kemampuan baca rumus matematika di peramban Web pilihan Anda.[5] Belakangan, mesin WebKit mulai berniat mendukung pengembangan MathML.

Pengguna mesin blog WordPress bisa mencoba plugin XHTML5 Support.[6] Plugin ini mampu mengonversi tag sebelumnya ke tag XHTML5. Juga menjaga kompatibilitas antarperamban Web.

Bacaan

  1. Polyglot Markup: HTML-Compatible XHTML Documents (w3.org).
  2. XHTML5 in a Nutshell (Sergey Mavrody, blog.whatwg.org, 2010).
  3. HTML5 Validator (validator.nu).
  4. W3C Validator Updated to Version 0.83 (Dani Iswara .Net).
  5. Menulis Matematika di Weblog WordPress dengan MathML (Dani Iswara .com).
  6. Plugin WordPress XHTML5 Support (wordpress.org).

11 tanggapan untuk “XHTML5 Poliglot plus SVG dan MathML”

Bli Dani,
Keluar jalur, saya mencoba bermain-main dengan versi mobile, hasil validasinya valid, tetapi ada warning penggunaan !doctype. Bisa share bli, penulisan yang benar untuk doctype-nya?
Sudah coba utak-atik malah errornya tambah banyak.

Pak Aldy,
[OOT] Dicek pakai yang mana, Pak? W3C Mobile OK Checker atau Ready.mobi? Yang ready.mobi lebih informatif, menurut saya.

Validasi versi mobile menurut saya akan benar-benar sukses (skor 100 di W3CMobileOK atau 5 dari maks. 5 di ready.mobi) secara normatif jika:
a) selain situs Web versi desktop, menyediakan juga antarmuka Web dengan doctype khusus versi mobile. Butuh sentuhan di sisi server. Atau, di WordPress banyak plugin-nya.
b) memakai doctype versi mobile untuk semua versi. Memudahkan pemeliharaan.

Saat ini dikenal doctype WAP dan XHTML Mobile.

Oleh Penulis Artikel

Saya mengeceknya di W3C Mobile OK Checker, salah satu penyebabnya karena doctype, yang digunakan belum versi mobile, saya mencoba mengubahnya, tetapi kesalahan justru bertambah :(

Selain itu masalah image juga. Dan yang membuat saya bingung ada pesan kesalahan no-chace or max-age=0, consider using the Last Modified and/or ETag.

Mohon solusi Bli.

Pak Aldy,
Saya pernah menulisnya dulu di Dani Iswara .Net:
a) Validasi Desain Web Mobile-Friendly.
b) Halaman/Aplikasi Web Versi Mobile.
Mengenai pengaturan cache, mungkin ada plugin WordPress untuk itu. Pemakaian ETag sudah pernah dicecar Pakde Harry—yang sudah bangkit lagi sekarang—saat membahas Page Speed. Lihat kembali Cache, Skor Page Speed, YSlow, W3C Mobile (Dani Iswara .com).

Menurut saya, tidak semua rekomendasi W3CMobileOK ideal untuk segala kondisi, saat ini. Lebih aman melakukan user testing. Doctype, ETag, ukuran berkas, bisa diabaikan. Saya ada rencana untuk menuliskannya nanti. Kebetulan Pakde Harry ada pertanyaan terkait itu.

Oleh Penulis Artikel

Tapi nyatanya, pengguna dan penyaji konten Web kebanyakan memakai dokumen text/html. Walaupun menuliskan tipe dokumen XHTML 1.0 Transitional, Strict, atau XHTML 1.1 di kode sumbernya. Artinya, di mata peramban Web, dokumen tersebut sama saja dengan HTML.

saya setuju. Untuk XHTML 1.0 memang ada pengecualian (tercantum di Appendix C).
Mmh, baru tahu kalau W3C Validator update dan menyesuaikan. saya sendiri lebih suka main ke validator.nu

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan. Ruas yang wajib ditandai *

Situs ini menggunakan Akismet untuk mengurangi spam. Pelajari bagaimana data komentar Anda diproses.