Rumah >hujung hadapan web >html tutorial >Mekanisme pemilihan mod DOCTYPE oleh pelayar terkenal_HTML/Xhtml_Pengeluaran halaman web
Penukaran mod yang disertakan dalam artikel ini digunakan untuk Firefox dan penyemak imbas berasaskan Gecko lain, Safari, Chrome dan penyemak imbas berasaskan Webkit lain, Opera, Konqueror, Internet Explorer untuk Mac, Internet Explorer untuk Windows dan penyemak imbas IE terbenam. Elakkan menyebut nama enjin penyemak imbas dan sebaliknya sebut nama penyemak imbas paling terkenal menggunakan enjin tersebut.
Artikel ini memfokuskan pada mekanisme pemilihan mod dan bukannya mendokumentasikan gelagat tepat setiap mod.
Berikut ialah mod yang berbeza:
Pemilihan mod untuk kandungan teks/html bergantung pada doctype sniffing (dibincangkan kemudian dalam artikel ini). Dalam IE8, mod bergantung pada faktor lain juga. Walau bagaimanapun, secara lalai dalam IE8, mod untuk tapak bukan intranet yang tiada dalam senarai hitam Microsoft bergantung pada jenis dokumen.
Tidak boleh terlalu ditekankan bahawa kelakuan tepat corak berbeza dalam setiap penyemak imbas, walaupun ia dibincangkan secara seragam dalam artikel ini.
Dalam Firefox, Safari, Chrome dan Opera, jenis kandungan HTTP aplikasi/xhtml xml (bukan elemen meta mahupun doctype!) akan mencetuskan mod XML. Dalam mod XML, penyemak imbas cuba memberikan pemprosesan yang betul spesifikasi dokumen XML setakat yang dinyatakan dalam penyemak imbas.
IE6, 7 dan 8 tidak menyokong application/xhtml xml, begitu juga Mac IE5.
Dalam penyemak imbas Nokia S60 berdasarkan WebKit, jenis kandungan HTTP aplikasi/xhtml xml tidak boleh mencetuskan mod XML, kerana tumpuan dalam taman berdinding mudah alih adalah keserasian dengan kandungan bukan standard. ("pelayar mudah alih" yang lebih lama tidak boleh menggunakan penghurai XML sebenar kerana kandungan bukan kanonik ditandakan sebagai XML.)
Memandangkan tidak cukup menguji Konqueror, saya tidak dapat menyatakan dengan tepat apa yang akan berlaku dalam penyemak imbas ini.
Sesetengah enjin mempunyai mod yang tiada kaitan dengan kandungan web. Untuk kesempurnaan, mereka hanya disebut di sini. Opera mempunyai mod WML2.0. WebKit pada Leopard mempunyai mod khusus untuk widget Papan Pemuka lama.
Berikut ialah kesan utama corak ini:
Mod teks/html terutamanya mempengaruhi reka letak CSS. Sebagai contoh, ini adalah kebiasaan bahawa jadual tidak mewarisi gaya. Dalam beberapa mod aneh pelayar, model kotak menjadi model kotak IE5.5. Dokumen ini tidak menyenaraikan semua ciri reka letak.
Dalam mod separa standard (dalam penyemak imbas dengan mod ini), hanya ketinggian sel jadual yang mengandungi imej berbeza daripada dalam mod standard.
Dalam mod XML, pemilih mempunyai gelagat sensitif huruf besar yang berbeza. Selain itu, peraturan khusus untuk elemen badan HTML tidak digunakan pada penyemak imbas lama yang tidak melaksanakan perubahan CSS 2.1 terkini.
Terdapat juga keanehan yang mempengaruhi penghuraian HTML dan CSS dan boleh menyebabkan halaman web yang mematuhi piawaian dihuraikan secara tidak betul. Reka letak unik menentukan sama ada kebiasaan ini didayakan atau tidak. Walau apa pun, adalah penting untuk memahami persamaan dan perbezaan utama antara mod Quirks dan mod Standard dalam reka letak dan penghuraian CSS (bukan penghuraian HTML).
Sesetengah orang tersilap merujuk kepada mod standard sebagai "mod penghuraian ketat", yang membawa kepada salah faham tentang keupayaan penyemak imbas untuk menguatkuasakan peraturan sintaks HTML dan keupayaan penyemak imbas untuk menilai penanda untuk ketepatan. Ini tidak berlaku. Walaupun reka letak mod standard berkuat kuasa, penyemak imbas masih melakukan kerja pembetulan sup tag (http://en.wikipedia.org/wiki/Tag_soup). (Sebelum keluaran Netscape 6 pada tahun 2000, Mozilla memang mempunyai mod penghuraian untuk menguatkuasakan peraturan sintaks HTML. Mod ini tidak serasi dengan kandungan Web sedia ada dan telah ditinggalkan.)
Satu lagi tanggapan yang salah adalah mengenai penghuraian XHTML. Secara amnya dipercayai bahawa menggunakan doctype XHTML menghasilkan penghuraian yang berbeza. Sebenarnya, ini tidak berlaku pada dokumen XHTML dengan jenis kandungan teks/html menggunakan penghurai yang sama seperti dokumen HTML. Pada masa ini semua pelayar mengambil berat tentang bahawa XHTML dengan jenis dokumen teks/html hanyalah "tag sup dengan crouton" (slash tambahan di mana-mana).
Hanya apabila dokumen yang menggunakan jenis dokumen XML (contohnya: application/xhtml xml atau xmapplication/) akan mencetuskan mod XML untuk penghuraian, penghurai pada masa ini berbeza sepenuhnya daripada penghurai HTML.
Walaupun Mod Quirks kebanyakannya mengenai CSS, terdapat juga sedikit tentang skrip. Sebagai contoh, dalam mod kebiasaan Firefox, atribut id HTML menetapkan rujukan objek berskop skrip global seperti dalam IE. Kesan skrip dalam IE8 patut diberi perhatian lebih daripada pelayar lain.
Dalam mod XML, gelagat sesetengah API DOM adalah berbeza sama sekali, kerana gelagat API DOM XML tidak serasi dengan gelagat HTML apabila ia ditakrifkan.
Pelayar moden menggunakan doctype sniffing untuk menentukan mod enjin dokumen teks/html. Ini bermakna pilihan mod adalah berdasarkan pengisytiharan jenis dokumen (atau kekurangannya) pada permulaan dokumen HTML. (Ini tidak terpakai pada dokumen yang menggunakan jenis dokumen XML.)
Pengisytiharan jenis dokumen (doctype) ialah pemalsuan tatabahasa SGML ialah rangka kerja penanda gaya lama dan HTML sebelum HTML5 ditakrifkan berdasarkannya. Dalam spesifikasi HTML4.01, pengisytiharan jenis dokumen menerangkan maklumat versi HTML. Walaupun nama "Pengisytiharan Jenis Dokumen" dan spesifikasi HTML 4.01 yang menerangkan "maklumat versi", Pengisytiharan Jenis Dokumen tidak mengklasifikasikan dokumen SGML atau XML sebagai jenis dokumen tertentu, walaupun ia kelihatan seperti itu (kerana namanya) . (Lagi dalam lampiran)
Spesifikasi HTML4.01 mahupun ISO 8879 (SGML) tidak menyatakan apa-apa tentang menggunakan pengisytiharan jenis dokumen sebagai penukaran mod enjin. Doctype sniffing adalah berdasarkan pemerhatian bahawa pada masa doctype sniffing direka, sebahagian besar dokumen unik tidak mempunyai pengisytiharan jenis dokumen mahupun rujukan kepada DTD yang lebih lama. HTML5 menerima fakta ini dan mentakrifkan doctype dalam teks/html sebagai satu-satunya penukaran mod.
Pengisytiharan jenis dokumen pra-HTML5 biasa mengandungi (dipisahkan dengan ruang kosong) rentetan "". Pengisytiharan jenis dokumen diletakkan sebelum teg pembukaan elemen akar dokumen.
Berikut ialah panduan ringkas tentang cara memilih jenis dokumen semasa membuat teks/dokumen html baharu:
Saya tidak mengesyorkan sebarang jenis dokumen XHTML kerana XHTML yang digunakan sebagai teks/html dianggap berbahaya . Walau apa pun, jika anda memilih untuk menggunakan doctype XHTML, ambil perhatian bahawa pengisytiharan XML akan mencetuskan mod kebiasaan dalam IE6 (tetapi bukan IE7!).
Garis panduan mudah untuk aplikasi/xhtml xml ialah jangan sekali-kali menggunakan doctype. Halaman web dengan cara ini tidak "selaras sepenuhnya" dengan XHMTL 1.0, tetapi itu tidak penting. (Sila lihat Lampiran di belakang)
A List Apart pernah memperkenalkan bahawa sebagai tambahan kepada doctype, IE8 akan menggunakan penukaran mod berdasarkan elemen meta sebagai salah satu faktor dalam pemilihan mod. (Lihat Ian Hickson, David Baron, David Baron sekali lagi, Robert O'Callahan dan Maciej Stachowiak komen . )
IE8 mempunyai 4 mod: mod quirks IE5.5, mod standard IE7, mod quasi-standard IE8 dan mod standard IE8. Pilihan mod bergantung pada data daripada beberapa sumber: doctype, elemen meta, pengepala HTTP, data muat turun berkala daripada Microsoft, domain LAN, tetapan yang dibuat oleh pengguna, tetapan yang dibuat oleh pentadbir LAN dan mod bingkai induk (jika mana-mana) Serasi dengan butang paparan bar alamat dicetuskan oleh pengguna. (Untuk apl lain yang dibenamkan dalam enjin, mod juga bergantung pada apl terbenam.)
Nasib baik, IE8 biasanya akan menggunakan doctype sniffing seperti pelayar lain jika:
Kecuali untuk dua kes di atas berkenaan X-UA-Compatible, IE8 melakukan doctype sniffing seperti IE7. Emulasi IE7 dipanggil paparan keserasian.
Dalam kes X-UA-Compatible, IE8 berkelakuan sama sekali berbeza daripada penyemak imbas lain. Saya ingin melihat Lampiran atau carta alir dalam format PDF dan PNG di halaman ini.
Malangnya, tanpa pengepala HTTP Serasi X-UA atau teg meta, walaupun dengan doctype yang sesuai, IE8 membenarkan pengguna menurunkan taraf halaman secara tidak sengaja daripada mod standard IE8 kepada mod IE7, yang merupakan mod standard IE7 emulasi. Lebih teruk, pentadbir LAN juga boleh melakukan ini. Microsoft juga boleh menyenaraihitamkan semua nama domain yang anda gunakan.
Untuk menangani kesan ini, doctype tidak mencukupi, anda memerlukan pengepala HTTP dan meta tag yang Serasi X-UA.
Berikut ialah panduan ringkas tentang cara memilih pengepala HTTP Serasi X-UA atau teg meta untuk dokumen teks/html baharu yang sudah mempunyai doctype yang mencetuskan mod standard atau mod separa standard dalam penyemak imbas lain:
Doctype sniffing ialah pendekatan seperti tag chowder untuk menyelesaikan masalah tag chowder. Doctype sniffing ialah heuristik yang direka bentuk selepas keluaran spesifikasi HTML4 dan CSS2 yang membezakan dokumen lapuk daripada dokumen yang mematuhi tingkah laku yang mungkin dijangkakan oleh pengarangnya.
Kadangkala dicadangkan untuk menggunakan doctype sniffing pada XML untuk menjadualkan pemprosesan yang berbeza, mengenal pasti perbendaharaan kata yang digunakan atau mengaktifkan ciri. Ini adalah idea yang tidak baik. Penjadualan dan pengenalan perbendaharaan kata hendaklah berdasarkan ruang nama, manakala pengaktifan ciri hendaklah berdasarkan arahan atau elemen pemprosesan yang jelas.
Keseluruhan idea pembentukan yang baik adalah untuk memperkenalkan penghuraian XML bebas DTD dan mempromosikan dokumentasi bebas doctype. Dalam kes rasmi di mana dua dokumen XML mempunyai bentuk kanonik yang sama dan aplikasi memprosesnya secara berbeza (dan perbezaannya bukan disebabkan oleh kekurangan pilihan untuk memproses entiti luaran), aplikasi mungkin rosak. Dalam amalan, jika dua dokumen XML menyebabkan kandungan yang sama dilaporkan (nama q diabaikan) kepada pengendali kandungan
SAX2 dan aplikasi memproses dokumen secara berbeza, aplikasi mungkin rosak. Memandangkan sebagai pengarang web, anda tidak boleh mempercayai bahawa semua orang akan menggunakan pemproses XML yang menyelesaikan entiti tambahan untuk menghuraikan halaman mereka (walaupun sesetengah penyemak imbas nampaknya berbuat demikian kerana mereka memetakan pengecam awam tertentu kepada DTD penentu entiti terpotong), Memasukkan doctypes ke dalam XML untuk Web adalah sia-sia dan sering membawa kepada tabiat pemujaan kargo. (Anda masih menggunakan ciri penggantian DTD W3C Validator untuk mengesahkan DTD, walaupun Pengesah W3C akan mengatakan bahawa hasilnya hanya sah buat sementara waktu. Atau lebih baik lagi, anda boleh berehat NG dengan Sahkan , ia tidak mencemarkan dokumen yang dirujuk oleh skema ) Memerlukan doctype untuk menghidu adalah agak bodoh, walaupun itu adalah penyelesaian dalam amalan HTML. Selain itu, apabila spesifikasi peringkat rendah mentakrifkan dua perkara sebagai sama, spesifikasi peringkat lebih tinggi tidak seharusnya cuba memberikan maksud yang berbeza. Sila pertimbangkan . Jika anda mengalih keluar pengecam awam, DTD yang sama masih dinyatakan, jadi doctype bermaksud sama seperti doctype sebelumnya. Patutkah mereka dihidu secara berbeza? Boleh berteori lagi. Andaikan bahawa DTD yang dipanggil foobar.dtd disalin ke example.com: . Bagaimana untuk menghidu ini? Ia sepatutnya bermaksud perkara yang sama. Malah keseluruhan DTD boleh dilampirkan pada dokumen. Dalam erti kata lain, jika terdapat #include "foo.h", anda tidak seharusnya mengikat mana-mana ilmu hitam pada nama foo.h, kerana ia sepatutnya membenarkan penyalinan kandungan foo.h ke dalam dokumen atau menyalin foo. h ke dalam bar.h dan bermaksud #include "bar.h". Sebab saya tidak bimbang tentang HTML dan SGML membina parameter yang sama ialah penyemak imbas web tidak menggunakan penghurai SGML sebenar untuk menghuraikan HTML, jadi saya tidak fikir berpura-pura menjadi SGML adalah berguna. Bagaimanapun, jika anda masih belum yakin, inilah artikel W Eliot Kimber tentang perkara itu comp.text.sgml Dalam jadual di bawah, mod quirk, mod standard dan quasi-standard masing-masing diwakili oleh Q, S dan A. Apabila penyemak imbas hanya mempunyai dua mod, jika ketinggian baris sel jadual adalah konsisten dengan mod standard Mozilla, mod standard ditandakan "S". maka ia ditandakan sebagai "A". Sila ambil perhatian bahawa XHTML yang disajikan menggunakan model kandungan XML dipaparkan dalam mod XML. Tujuan jadual ini bukan untuk mengatakan bahawa semua doctype dalam jadual adalah pilihan yang munasabah untuk halaman baharu. Tujuan jadual ini adalah untuk menunjukkan data berdasarkan cadangan saya. Simbol singkatan berikut digunakan untuk pengepala lajur: Lampiran: Cara mengendalikan beberapa jenis doc dalam teks/html
Kod menghidu jenis doctype Moziila telah diubah suai dengan ketara pada Oktober 2000, September 2001 dan Jun 2002. Status binaan Mozilla (dan Netscape 6.x) yang diterangkan dalam dokumen ini boleh dilihat di ftp.mozilla.org pada 2000.10.19. Dokumen ini tidak merangkumi cara doctype sniffing berfungsi dalam Mozilla M18 (dan Netscape 6.0 PR3). Kod menghidu doctype Safari juga telah diubah suai dengan ketara sejak versi beta awam yang pertama. Dokumen ini tidak meliputi tingkah laku lebih awal daripada versi V73 yang juga dipanggil 0.9.
Kod doctype menghidu sebelum Konqueror 3.5 nampaknya datang daripada versi Safari yang sangat awal. Konqueror kini sepadan dengan Safari, dan kod sniffing doctypenya datang daripada Mozilla.
Seperti yang dapat dilihat daripada jadual, doktype menghidu Opera sentiasa berubah daripada serupa dengan IE kepada serupa dengan Mozilla, walaupun Opera 9.5 dan 9.6 sedang dalam perjalanan kembali. Pada masa yang sama, tingkah laku susun atur mod quirks Opera telah ditukar daripada meniru mod quirks IE6 kepada mod quirks Mozilla.