Rumah >hujung hadapan web >html tutorial >Mekanisme pemilihan mod DOCTYPE oleh pelayar terkenal_HTML/Xhtml_Pengeluaran halaman web

Mekanisme pemilihan mod DOCTYPE oleh pelayar terkenal_HTML/Xhtml_Pengeluaran halaman web

WBOY
WBOYasal
2016-05-16 16:42:401375semak imbas

Skop Dokumen

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.

Mod

Berikut ialah mod yang berbeza:

Mod dengan teks jenis kandungan/html

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.

Mod Quirks
Dalam Mod Quirks, penyemak imbas melanggar format web moden untuk mengelakkan halaman "pecah" yang dibuat berdasarkan amalan yang popular pada akhir 1990-an. Pelayar yang berbeza melaksanakan kebiasaan yang berbeza. Dalam Internet Explorer 6, 7 dan 8, mod quirks berkesan membekukan IE 5.5. Dalam pelayar lain, mod quirks ialah sisihan kecil daripada mod standard.
Jika anda membuat halaman web baharu, anda harus mematuhi spesifikasi yang berkaitan (terutamanya CSS2.1) dan menggunakan mod standard.
Mod Standard
Dalam Mod Standard, penyemak imbas cuba untuk menganggap dokumen yang mematuhi piawaian sebagai betul secara normatif seperti dalam penyemak imbas yang ditentukan .
Pelayar yang berbeza mengikut peringkat yang berbeza, jadi mod standard bukanlah satu matlamat.
HTML5 memanggil mod ini "no quirks mode"
Mod Hampir Standard (Mod Hampir Standard)
irefox, Safari, Chrome, Opera( Bermula dari 7.5) dan IE8 juga mempunyai mod yang dipanggil "mod kuasi-standard", yang melaksanakan saiz menegak sel jadual mengikut kaedah tradisional dan bukannya mengikut spesifikasi CSS2 dengan ketat. Mac IE5, Windows IE6 dan 7, versi sebelum Opera7.5, dan Konqueror tidak memerlukan mod separa piawai kerana sekurang-kurangnya mereka tidak mengikut spesifikasi CSS2 dengan ketat untuk melaksanakan dimensi menegak sel jadual dalam mod piawaian masing-masing. Malah, mod piawai mereka lebih hampir kepada mod separa piawai Mozilla daripada mod piawai Mozilla.
HTML5 memanggil mod ini sebagai "mod kebiasaan terhad".
Mod IE7
IE8 mempunyai mod yang kebanyakannya membekukan salinan mod piawaian IE7. Tiada pelayar lain yang mempunyai mod seperti ini, dan ia tidak ditentukan oleh HTML5.

Mod dengan aplikasi jenis kandungan/xhtml xml (mod XML)

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.

Mod Bukan Web

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.

Kesan

Berikut ialah kesan utama corak ini:

Reka letak

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.

Analisis

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.

Skrip

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.

menghidu doctype (juga dipanggil penukaran doctype)

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.

Pilih doctype

teks/html

Berikut ialah panduan ringkas tentang cara memilih jenis dokumen semasa membuat teks/dokumen html baharu:

Mod standard, pengesahan canggih
Jika anda ingin mengesahkan seperti , dan ciri baharu seperti ARIA, maka ini adalah perkara yang betul untuk dilakukan. Ambil perhatian bahawa takrifan berkesan HTML5 masih berubah, sila pastikan anda menguji penjajaran imej dalam Firefox, Safari, Chrome, Opera9 atau Opera10. Menguji penjajaran imej dalam Internet Explorer tidak mencukupi, bagaimanapun pastikan anda juga menguji dalam IE8.
Mod standard, sasaran pengesahan yang lebih stabil
Doctype ini juga akan mencetuskan mod standard dan definisi sah HTML4.01 yang berusia 10 tahun adalah stabil. Sila pastikan untuk menguji penjajaran imej dalam Firefox, Safari, Chrome, Opera9 atau Opera10. Menguji penjajaran imej dalam Internet Explorer tidak mencukupi, bagaimanapun pastikan anda juga menguji dalam IE8.
Untuk menggunakan mod standard, tetapi masih mengesahkan bahawa penanda atau menggunakan imej yang dihiris dalam reka letak jadual adalah tidak disyorkan dan tidak mahu membetulkannya.
Ia mencetuskan mod separa standard (dan mod Standard penuh lama dalam Mozilla). Sila ambil perhatian bahawa reka letak berdasarkan imej yang dihiris yang dilaksanakan menggunakan jadual mungkin dipecahkan jika dialihkan ke HTML5 pada masa hadapan (dan perkara yang sama berlaku untuk mod standard penuh).
Menggunakan mod quirks dengan sengaja
Tiada doctype.
Tolong jangan lakukan ini. Mereka bentuk secara sengaja untuk mod kebiasaan akan mengganggu anda, dan pada masa hadapan tiada sesiapa pun rakan sekerja atau pengganti anda akan mengambil berat tentang Windows IE6 (tiada siapa yang mengambil berat tentang Netscape 4.x dan IE5 lagi). Mereka bentuk untuk mod kebiasaan adalah idea yang tidak baik. Percayalah.
Jika anda masih mahu menyokong Windows IE6, adalah lebih baik untuk membuat penggodaman khas untuknya menggunakan komen bersyarat daripada membuat penyemak imbas lain kembali ke mod quirks.

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!).

aplikasi/xhtml xml

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)

komplikasi IE8

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:

  • Pengarang tidak menetapkan pengepala HTTP Serasi X-UA
  • Pengarang tidak menetapkan tag meta Serasi X-UA
  • Microsoft belum meletakkan nama domain tapak ini pada senarai hitam
  • Pentadbir LAN tidak meletakkan tapak ini pada senarai hitam
  • Pengguna tidak menekan butang Paparan Keserasian (atau sebaliknya ditambahkan pada senarai hitam pengguna tertentu)
  • Tapak ini bukan dalam domain LAN
  • Pengguna tidak memilih untuk menunjukkan semua tapak dalam IE7
  • Halaman tidak dibenamkan ke dalam halaman mod keserasian melalui bingkai

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:

Domain anda tiada dalam senarai hitam Microsoft, dan anda lebih bimbang dengan tiada gangguan khusus penyemak imbas daripada memastikan pengguna tidak boleh kembali kepada tingkah laku IE7.
Anda tidak perlu memasukkan pengepala HTTP Serasi X-UA atau teg meta.
Nama domain anda berada dalam senarai hitam Microsoft Kerana pengarang lain dalam nama domain anda telah merosakkan tapak atau menyebabkan pengguna mendayakan paparan keserasian untuk keseluruhan domain, anda bimbang Google atau Digg akan menggunakan bingkai untuk membenamkan anda. tapak atau tapak anda Untuk memastikan pengguna tidak boleh menggunakan paparan yang serasi
Pertama sekali, masukkan elemen meta berikut dalam halaman anda (ia adalah haram dalam HTML5) (sebelum sebarang elemen skrip), atau tetapkan pengepala HTTP berikut: Memecahkan
dalam IE8 Pertama, masukkan elemen meta berikut dalam halaman anda (ia adalah haram dalam HTML5)
(sebelum sebarang elemen skrip), atau tetapkan pengepala HTTP berikut:
Pautan berkaitan

Eric Meyer menulis tentang corak Mac IE5 dalam
    Menggunakan doctype yang betul
  • doctype menghidu untuk Mozilla
  • oleh David Baron Lance Silver membincangkan mod dan doctype sniffing dalam Windows IE6 dalam
  • Peningkatan CSS dalam IE6
  • penukaran doctype untuk Opera9
  • Penyelesaian Faruk Ateş
  • IE8 dan X-UA-Serasi
  • Tambahan: Rayuan kepada pelaksana XML dan pengarang spesifikasi

Sila jangan bawa doctype sniffing ke XML.

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

Lampiran: Cara mengendalikan beberapa jenis doc dalam teks/html

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:

NS6
Mozilla 0.6…0.9.4 dan Netscape 6.0…6.2.3
Moz Lama
Mozilla 0.9.5 hingga 1.1 alpha dan Mozilla 1.0
Moz & Safari & Opera 10 & HTML5
Mozilla 1.0.1, Mozilla 1.1 beta dan lebih tinggi, Firefox kepada Netscape 7, Safari 0.9 kepada Safari 4.0 beta, Opera 10, Chrome, Konqueror 3.5 , tingkah laku yang ditentukan HTML5
Opera 9.0
Opera 9.0…9.20
IE 8 & Opera 9.5
Tiada Mod X-UA-Compatible dan Compatible mengatasi lalai IE8 ("A" dalam kes ini bermaksud mod separuh standard IE8), Opera 7.5…8.54 dan 9.5…9.6
IE 7 & Opera 7.10
IE7, mod keserasian dan IE8 tanpa X- Liputan UA-Serasi ("A" dalam kes ini bermaksud mod IE7) dan Opera 7.10…7.23
IE 6 & Opera 7.0
Windows IE 6 dan Opera 7.0… 7.03
Mac IE 5
Mac IE 5.0…5.2.3
Konq 3.2
Konqueror 3.2.2…3.3 (mungkin juga termasuk 3.1…3.2 .1; Saya belum pasti lagi)

Doctype NS6 Moz Lama Moz & Safari & Opera10 & HTML5 Opera9.0 IE8 & Opera9.5 IE7 & Opera7.10 IE6 & Opera7.0 Mac IE5 Konq3.2
Tiada S S S S S S S S S
">HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> S S S S S S S S S
">HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> S S S S S A A A A
">HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> S S S S S A A S A
">HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/ html4/strict.dtd">
S S S S S A A A A
">HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
S S S S S A A A A
">HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> S S S S S S S S S
">HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> S S S S S S S S S
">HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR /html4/loose.dtd">
S S A A A A A A S
">HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR /1999/REC-html401-19991224/loose.dtd">

 

S S A A A A A A S
">HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR /html4/loose.dtd">
S S S S A A A A S
"> S S S S S A A A A
"> S S S S S A A A A
">html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/ DTD/xhtml1-strict.dtd"> S S S S S A A A A
">"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> S S A A A A A A S
"> S S S S S A S A S
"> S S S S S A S A S
">version="1.0" encoding="UTF-8"?> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> S S S S S A S A S
">version="1.0" encoding="UTF-8"?> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

 

S S A A A A S A S
">HTML PUBLIC "ISO/IEC 15445:2000//DTD HTML//EN"> S S S S S S S S S
">HTML PUBLIC "ISO/IEC 15445:2000//DTD HyperText Markup
Bahasa//EN">
S S S S S A A A S
">HTML PUBLIC "ISO/IEC 15445:1999//DTD HTML//EN"> S S S S S S S S S
">HTML PUBLIC "ISO/IEC 15445:1999//DTD HyperText Markup
Bahasa//EN">
S S S S S A A A S
S S S S S A A A  

Sejarah

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.

Lampiran: Pemilihan mod untuk IE8

Mula: Masukkan "meta Serasi X-UA?"
Meta Serasi X-UA? IE=EmulateIE7: Masukkan "quirks or no doctype? (mod compatibility)"
IE=IE8 or IE=IE7 or IE=a or IE=EmulateIE8 or no atau skrip pertama: masukkan "X-UA- Compatible Pengepala HTTP?"
IE=8 atau IE=Edge atau IE=99 atau IE=9.9: Masukkan "mod quasi-standards?"
IE=5: Gunakan mod quirks (IE5. 5)
)"
IE=IE8 atau IE=IE7 atau IE=a atau IE=EmulateIE8 atau tiada: Masukkan "Tunjukkan semua tapak...Preset?"
IE=8 atau IE=Edge atau IE=99 atau IE=9.9: Masukkan "mod quasi-standards?"
IE=5: Gunakan mod quirks (IE5.5)
Quacks mod atau tiada doctype? (mod keserasian)
Ya: Gunakan mod quirks (IE5.5)
Tidak: Gunakan mod standard IE7
Tunjukkan semua tapak... Pratetap ?
Ya: Masukkan "mod kebiasaan atau tiada doctype? (mod keserasian)"
Tidak: Masukkan "Tunjukkan tapak LAN...praset?"
Tunjukkan tapak LAN. ..sediakan pratetap?
Ya: Masukkan "Tapak ini terletak dalam domain LAN?"
Tidak: Masukkan "Nama domain ada dalam senarai yang diselenggara oleh Microsoft?" nama ada dalam senarai yang dikekalkan oleh Microsoft?
Ya: Masukkan "Mod aneh atau tiada doctype? (Mod keserasian)"
Tidak: Masukkan "Terbenam dalam Bingkai dengan halaman mod keserasian?" dengan Bingkai?
Ya: Pergi ke "Mod Quirks atau tiada doctype? (mod keserasian)"
Tidak: Pergi ke "Butang mod keserasian ditekan?"
Ya: Masukkan "mod kebiasaan atau tiada doctype? (mod keserasian)"
Tidak: Masukkan "mod quirks atau tiada doctype? (IE8)"
Mod Quirks atau Tiada doctype? (IE8)
Ya: Masukkan "Gunakan mod kebiasaan (IE5.5)"
Tidak: Masukkan "mod kuasi-standard?" mod?
Ya: Gunakan mod separuh standard IE8
Tidak: Gunakan mod standard IE8
Langkah ini boleh dilihat sebagai carta alir dalam format
PDF
dan
PNG
.
Terima kasih
Terima kasih kepada Simon Pieters, Simon Pieters dan Anne van Kesteren kerana membantu saya membetulkan helaian corak untuk pelbagai versi Opera dan untuk komen mereka. Terima kasih kepada Simon Pieters kerana mencipta satu lagi carta alir IE8.
Kenyataan:
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn