Kenapa tidak XHTML5?

53

Jadi, HTML5 adalah Langkah Besar ke Depan, saya diberitahu. Langkah terakhir yang kami ambil yang saya sadari adalah pengenalan XHTML. Keuntungannya jelas: kesederhanaan, ketegasan, kemampuan untuk menggunakan parser dan generator XML standar untuk bekerja dengan halaman web, dan sebagainya.

Betapa aneh dan membuat frustasi, HTML5 menggulung semua itu: sekali lagi kami bekerja dengan sintaksis non-standar; sekali lagi, kita harus berurusan dengan bagasi historis dan kompleksitas parsing; sekali lagi kami tidak dapat menggunakan pustaka, parser, generator, atau transformer XML standar kami; dan semua keuntungan yang diperkenalkan oleh XML (ekstensibilitas, ruang nama, standardisasi, dan sebagainya), bahwa W3C menghabiskan satu dekade mendorong untuk alasan yang baik, hilang.

Baik, kami memiliki XHTML5, tetapi sepertinya belum mendapatkan popularitas seperti yang dimiliki pengkodean HTML5. Lihat pertanyaan SO ini , misalnya. Bahkan spesifikasi HTML5 mengatakan bahwa HTML5, bukan XHTML5, "adalah format yang disarankan untuk sebagian besar penulis."

Apakah saya salah fakta? Kalau tidak, mengapa saya satu-satunya yang merasakan hal ini? Mengapa orang memilih HTML5 daripada XHTML5?

— jameshfisher
sumber

6

+1 Saya melihat bahwa saya bukan satu-satunya yang frustrasi dengan hilangnya semua keunggulan XML di HTML5.

— Arseni Mourzenko

Membunyikan pertanyaan yang bagus, tentu saja.

— Konrad Rudolph

1

Saya harap saya bukan satu-satunya yang senang dengan kerugian semua kerugian XML di HTML5. Misalnya, mari kita bandingkan HTML5 yang valid dengan XHTML yang valid. HTML5 <!DOCTYPE html>Hello World

<?xml version="1.0" encoding="iso-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0  Transitional//EN" "DTD/xhtml1-transitional.dtd"><html xml:lang="en" lang="en" xmlns="http://www.w3.org/1999/xhtml"><head><title></title></head><body>Hello World</body></html>

— :,

@zzzzBov, Anda pasti bukan satu-satunya yang senang, dan itulah sebabnya saya mengajukan pertanyaan ini sejak awal. Juga: Anda tidak akan serius menulis <!DOCTYPE html>Hello World, bukan? Coba itu di validator ini .

— jameshfisher

1

@ eegg, tampaknya Anda belum membaca spesifikasi pada tag awal opsional , karena saya serius akan menulis <!DOCTYPE html>Hello World!, karena itu HTML5 yang benar-benar valid. Dokumen yang lebih pendek berarti lebih sedikit bandwidth yang setara dengan penghematan yang signifikan untuk perusahaan besar (sudahkah Anda melihat apa yang dikirim google untuk www.google.com?).

— zzzzBov

25

Saya akan merekomendasikan membaca Bagaimana Kami Sampai di Sini? . Mark Pilgrim memberikan sejarah HTML yang luar biasa dan singkat hingga HTML5.

Pada dasarnya, pemahaman saya adalah bahwa banyak halaman web bahkan tidak memanfaatkan "X" dari XHTML karena mereka tidak menentukan tipe MIME yang tepat untuk itu.

— tesis
sumber

18

Ya. Ringkasan saya tentang cerita itu adalah, "Hei, tidak ada yang sesuai dengan spesifikasi. Mungkin kita bisa membuat mereka sesuai dengan spesifikasi dengan menetapkan bahwa orang dapat membuat kesalahan yang mereka inginkan. Kemudian akhirnya semua dokumen kita akan bebas dari kesalahan. dan memenuhi standar. " Tidak ada gunanya menulis spesifikasi dengan asumsi awal bahwa tidak ada yang menghormati spesifikasi.

— jameshfisher

1

@ eegg, baris terakhir Anda menunjukkan ketidaktahuan Anda pada kenyataan. Banyak yang baik telah datang dari asumsi tidak ada yang sempurna . Daripada spec yang mengatakan, "jika Anda membuat kesalahan, semuanya rusak" itu malah mengatakan, "jika Anda membuat [jenis kesalahan ini] maka [hasil ini] adalah apa yang harus terjadi". Berapa banyak buku di rak kami jika mereka harus memiliki 100% ejaan, tanda baca, dan tata bahasa yang benar agar bisa diterbitkan?

— zzzzBov

6

@zzzzBov, analogi Anda dengan buku yang diterbitkan aneh. Mengapa parser HTML harus lebih memaafkan daripada parser untuk [bahasa lain di sini], di mana kesalahan sintaks bertemu dengan pesan kesalahan? Bayangkan kekacauan yang kita hadapi jika kompiler C kita mencoba yang terbaik untuk secara diam-diam menafsirkan kembali sintaksis yang rusak.

— jameshfisher

@ eegg, saya dapat membayangkan apa yang akan terjadi jika parser untuk bahasa lain bereaksi terhadap kesalahan sintaksis dengan cara yang lebih memaafkan: kita akan menghabiskan lebih sedikit waktu memburu tanda kurung yang salah tempat dan kehilangan titik dua semula dan lebih banyak waktu mengetik kode fungsional. Saya tidak mengatakan bahwa pemrogram yang baik tidak akan tetap membuat program mereka terbentuk dengan baik, tetapi tentu akan membantu pemrogram biasa-biasa saja menulis kode kerja. Suatu Cprogram mungkin akan tampak jauh lebih mirip dengan sebuah Pythonprogram di mana semi-titik dua dan kurung sebagian besar bisa menghilang, dan apa yang akan tersisa adalah kode penting.

— zzzzBov

“Sumber daya yang diminta /past.htmltidak lagi tersedia di server ini dan tidak ada alamat penerusan.”

— Marco

6

Jika Anda menghasilkan html5 yang kompatibel dengan xml, dan mengirimkannya dengan xml sebagai tipe mime, maka parser xml akan digunakan untuk semua jazz yang bagus;)

EDIT: lihat itu untuk beberapa informasi lebih lanjut: http://wiki.whatwg.org/wiki/HTML_vs._XHTML

— deadalnix
sumber

Tentukan "jazz yang bagus". AFAIK tidak ada untungnya untuk mem-parsing HTML sebagai XML. Menghasilkan dan mentransformasikan adalah hal-hal lain, itu bisa nyaman, tetapi parsing dengan sendirinya tidak menawarkan keuntungan, hanya kerugian (itu membuat bug kosmetik fatal).

— Joeri Sebrechts

3

@ Joeri Fakta bahwa jauh lebih mudah untuk diuraikan adalah keuntungan dalam buku saya, karena berbagai alasan (penguraian ketat memfasilitasi penemuan kesalahan, dukungan alat yang lebih baik karena alat lebih mudah untuk ditulis, sanitasi input yang lebih mudah, dll.).

— Konrad Rudolph

Anda juga dapat menyediakan beberapa fungsi yang tidak tersedia di html standar, seperti micin xhtml dengan konten xml lainnya, dan umumnya menggunakan semua fungsi xml, ruang nama untuk contoh. html parser dapat memperbaiki kode sumber yang buruk - bug kosmetik seperti yang Anda sebut-, tetapi perbaikan tersebut memiliki harga. Harganya adalah bahwa browser perlu tahu apa yang mungkin ditemukan dalam kode, sehingga membatasi fungsi yang tersedia.

— deadalnix

3

HTML5 adalah kesimpulan logis dan tak terhindarkan dari browser yang mengadopsi hukum Postel ("Jadilah liberal dalam apa yang Anda terima").

Setelah satu browser dengan pangsa pasar yang cukup mengadopsi prinsip ini, yang lain dipaksa untuk mengikuti, tidak hanya menjadi liberal dengan menerima konten yang tidak sesuai, tetapi juga merendernya dengan cara yang sama seperti yang dilakukan pesaing mereka. HTML5 adalah hasil logis dari situasi itu: vendor browser telah memutuskan bahwa karena mereka tidak akan menolak konten apa pun sebagai tidak valid (setidaknya, tidak pada level HTML - Javascript adalah masalah lain!) Mereka mungkin juga duduk di sekitar meja dan menyetujui interpretasi untuk apa pun yang mungkin dilontarkan oleh penulis konten. Dalam lingkungan ini, mereka tidak bereaksi dengan baik terhadap para geek standar yang mengatakan kepada mereka bahwa jika saja mereka menolak konten yang salah dari kata go, mereka tidak akan terlibat dalam kekacauan ini.

Jadi Anda dan saya bisa berteriak dari sela-sela dan memberi tahu vendor peramban dan penggunanya bahwa dunia akan menjadi tempat yang lebih baik jika mereka tidak percaya pada John Postel, tetapi kerusakan telah terjadi dan sangat sulit untuk membatalkannya.

— Michael Kay
sumber

3

Kisah kecerobohan browser yang bersaing cukup benar. Tapi ada satu hal: itu sebabnya standar-Geeks ada. Jika semua browser menerapkan yang lurus dan sempit sejak awal, organisasi seperti W3C tidak perlu berada di sini untuk menjaga semuanya tetap terkendali. Inti dari standar adalah pengendalian kerusakan; bagi badan standar untuk menyerah dan menerima kecerobohan mengalahkan tujuan utamanya.

— jameshfisher

1

@ eegg: HTML5 mendefinisikan kembali aturan parsing untuk membuat semua input valid dan masih memiliki konsekuensi yang dapat diprediksi. Jika kesalahan sintaks tidak mungkin, seluruh kelas bug dikesampingkan sejak awal. Kemampuan XML untuk mendapatkan kesalahan parse adalah cacat desain, dan harus diakui demikian.

— Joeri Sebrechts

1

@ Joeri, posisi Anda tampaknya seperti spec HTML5, diambil pada kesimpulan logis yang gila. "HTML5 mendefinisikan kembali aturan parsing untuk membuat semua input valid" - tidak. Konsep kesalahan parsing masih ada. "Jika kesalahan sintaks tidak mungkin, seluruh kelas bug dikesampingkan sejak awal" - mungkin ini parodi? Logika ini adalah apa yang saya singgung diparafrasekan dalam komentar saya untuk jawaban @pesis. Ya, kelas kesalahan sintaks dihapus, untuk digantikan oleh kelas yang lebih besar dari kesalahan koreksi sintaksis peramban .

— jameshfisher

2

Spesifikasi HTML5 sebenarnya telah sangat ditingkatkan dibandingkan spesifikasi HTML4. Secara khusus, penanganan kondisi kesalahan dan markup yang tidak valid sebenarnya distandarisasi, artinya semua browser yang menerapkan standar dengan benar akan menangani markup yang tidak valid dengan cara yang sama.

HTML ditulis oleh manusia lebih sering daripada tidak (biasanya bersamaan dengan semacam bahasa templating), dan manusia membuat kesalahan. Selama semua browser menangani kesalahan sintaks dengan cara yang sama, maka aturan "menjadi liberal dalam apa yang Anda terima" sangat dapat diterima.

Hanya ada sedikit keuntungan dalam menghasilkan XML yang valid, karena alat dan perpustakaan untuk menangani HTML (hampir) sama tersedia, dan HTML lebih mudah bagi manusia untuk menulis daripada XML.

— Dean Harding
sumber

Lebih dari spesifikasi HTML4 , ya. Tapi poin saya adalah bahwa XHTML1.1 sudah diperbaiki. Alat / pustaka untuk menangani HTML cenderung seperti BeautifulSoup - sementara alat yang hebat, mereka harus mati bersama dengan halaman yang dibuat untuk diurai.

— jameshfisher

1

Anda tidak akan pernah mendapatkan manfaat dari parser sederhana atau alat XML standar di sisi klien.

Ada miliaran halaman di web dalam HTML, beberapa di antaranya ditulis oleh orang yang sudah lama mati, jadi mereka tidak akan pernah diperbarui ke XML. Jadi, jika Anda ingin membuat agen pengguna yang bermanfaat secara umum, Anda harus dapat mem-parsing HTML kuno. Bisa dibilang XHTML hanya memperkenalkan kompleksitas tambahan karena membutuhkan mode parsing baru selain parsing HTML yang sudah Anda dukung.

Di sisi server Anda masih dapat memanfaatkan alat XML misalnya. menghasilkan XHTML menggunakan XSLT. Tetapi jika Anda tidak secara khusus menggunakan rantai alat XML, tidak ada manfaat menggunakan sintaks XML daripada hanya HTML.

(Anda tidak benar bahwa HTML adalah sintaks "non-standar". Sintaks HTML ditentukan dengan sangat teliti dalam spesifikasi HTML5, jadi ini sama standarnya dengan sintaks XML.)

— JacquesB
sumber