模式的由來:從混亂到標準的歷史演進
什麼是渲染模式?
瀏覽器的排版引擎主要有三種渲染模式:怪異模式、近標準模式 和 標準模式。這種區分源自網頁標準發展的歷史。回到網際網路的早期年代,瀏覽器巨頭各行其道:開發者往往需要為 Netscape Navigator 寫一版頁面,為 Internet Explorer 再寫一版。由於當時缺乏統一標準,不同瀏覽器對 HTML/CSS 的詮釋各有差異。直到 late 90年代 W3C 推出了網頁標準(如 HTML4、CSS2),情況才開始改變。
然而,新標準帶來一個兩難:如何在推行標準的同時,不破壞舊網站? 如果瀏覽器一夜之間完全依照嚴格標準解析,那些根據舊瀏覽器慣性撰寫的舊網站版面將會亂成一團。為了解決兼容性問題,瀏覽器廠商想出了一個折衷方案——「雙模機制」。也就是說,瀏覽器可以用兩種不同方式來解析網頁:遇到現代標準編寫的頁面,就用標準模式;遇到疑似老舊的頁面,則切換到怪異模式,盡量模擬老瀏覽器的行為。如此一來,新網站享受標準的好處,舊網站也能維持原樣,不至於完全崩壞。
DOCTYPE的角色
怎麼判斷一個頁面該用哪種模式?答案就是看 HTML 文件開頭的 DOCTYPE 宣告。DOCTYPE 原是用來聲明文件類型的指令,但在瀏覽器實作上,它的主要作用變成了「觸發渲染模式」。從2000年代初期開始(例如 IE6 及 Netscape/Mozilla 等瀏覽器),開發者若在HTML第一行加上一個標準的 DOCTYPE,瀏覽器就會以標準模式呈現頁面;反之,缺少 DOCTYPE 或使用了過時/怪異的 DOCTYPE,瀏覽器則會退回怪異模式來解析。可以說,DOCTYPE 是開發者與瀏覽器之間的一個暗號:(或其他正確的DOCTYPE)意思是「放心按標準來吧!」;而若沒有這個暗號,瀏覽器會想:「嗯,這可能是個老舊頁面,啟動兼容模式以防萬一。」此外,部分特定的過渡時期DOCTYPE(例如 XHTML 1.0 Transitional)在某些瀏覽器中會觸發 近標準模式,介於兩者之間(稍後會解釋其特殊之處)。
值得注意的是,現行的 HTML5 doctype 非常簡潔,就是 ,放在文件最開頭即可。這個宣告唯一的作用就是啟用標準模式。在 HTML5 時代,已沒有任何理由使用其他複雜的 DOCTYPE;任何現代瀏覽器看到 都會乖乖進入標準模式(即便是過去以怪異模式臭名昭著的 IE 瀏覽器,在 IE9 之後遇到這個宣告也會進入標準模式)。總之,在了解歷史之後,給各位開發者的一句箴言就是:永遠在HTML檔案最頂端正確地寫下 DOCTYPE,如此就能避免大多數怪異模式的陷阱。
三種模式解析差異大觀
標準模式 (Standards Mode):遵循當前 HTML、CSS 規範詮釋頁面。瀏覽器盡可能依 W3C 標準行事,各家瀏覽器之間的差異減至最小。我們理想中寫的程式碼,都希望在這種模式下執行。
怪異模式 (Quirks Mode):模擬上世紀末舊式瀏覽器的怪異行為,以兼容老舊內容。瀏覽器在此模式下放寬規則,允許許多不嚴謹甚至錯誤的寫法照樣生效,同時再現早期排版的種種「怪癖」。換句話說,怪異模式其實就是瀏覽器的復古模式——彷彿把你帶回 1999 年的網頁世界。這意味著部分 CSS 特性和盒模型計算方式會退回舊版瀏覽器的邏輯,某些新標準功能則被關閉或改變。
近標準模式 (Almost Standards Mode):顧名思義,接近標準模式 幾乎與標準模式相同,只保留極少數舊瀏覽器的怪癖。它有時也稱為「有限怪異模式 (Limited Quirks Mode)」,因為僅一兩項舊行為被保留下來。實際上,最著名的差異在於表格單元格的高度計算:在近標準模式中,包含圖片的表格儲存格高度計算方式略有不同,以解決老舊頁面中的垂直對齊問題。除此之外,近標準模式和標準模式幾乎沒有可察覺的差別。這種模式通常由少數過渡時期的 DOCTYPE 觸發(例如部分 XHTML/HTML4 過渡DTD),目的是在向標準模式過渡時,保留關鍵的小怪癖避免版面走樣。
了解了模式的大致概念,以下我們以HTML/CSS 行為差異為主軸,列出在不同模式下可能遇到的具體現象:
CSS盒模型差異
這是最經典也最影響版面的差異。在標準模式下,瀏覽器採用W3C的CSS盒模型規則:元素設定的 width 和 height 僅計算內容區域,不包含內邊距(padding)和邊框(border)。例如一個 div 設定寬度100px,邊框和內距各5px,則最終渲染時這個元素佔據的實際寬度是 100 + 5×2 + 5×2 = 120px。在怪異模式下則回到傳統盒模型:元素的寬高計算包含內邊距和邊框。也就是說,同樣設定下,最終寬度仍為100px(內邊距和邊框被"算進去"寬度裡,而非額外增加)。這種差異源自 IE5 時代的實作——早期 IE 瀏覽器的盒模型算法與標準不符,將 border 和 padding 都算在 width 內。現代瀏覽器在怪異模式中會故意復刻這種行為以防老網站版面走樣。
Margin 折疊與間距處理
標準模式遵循嚴謹的 margin 折疊規則,例如兩個垂直相鄰的區塊元素其上下外距會發生折疊(取較大者),或者一個子元素的頂部外距會與父容器的頂部外距折疊等。怪異模式下,瀏覽器為了相容舊頁面,對 margin 的處理有所不同,常見怪癖包括:垂直外邊距不折疊或計算方式異常。例如在怪異模式中,
圖片與文字垂直對齊
曾經讓許多新人抓狂的一件事是,將放在文字中時,圖片下方往往會有細小的空白間隙。在標準模式,這個現象是因為預設情況下圖片作為行內元素和文字基線對齊,文字的底部留有下行空間(為字母如"g"、"y"的尾巴保留的空隙),導致圖片下方也出現那麼一條縫隙。如果要求圖片貼齊容器底部,就需要調整 CSS(例如將圖片的 vertical-align 設為 middle 或 bottom)。在怪異模式 下,瀏覽器的處理則更接近舊式瀏覽器:有些瀏覽器會將行內圖片預設直接底對齊容器,因而消除了那條底部空隙。換句話說,怪異模式往往不會出現標準模式下常見的
下方小空白。此外,怪異模式中還有個經典怪癖:早期IE會自動給浮動的圖片增加約3像素的下方間距,以防文字貼得太緊。現代瀏覽器在怪異模式裡也復現了類似的效果,在圖片底部或周圍留出些微空白,以達到與舊版瀏覽器一致的視覺結果。
CSS 選擇器與大小寫
按照標準,HTML 的 class 和 id 名稱是區分大小寫的嗎?其實在 HTML (text/html) 中,屬性值一般不區分大小寫,但 CSS 選擇器 根據規範是區分大小寫的(除非 HTML 標準另有規定)。在標準模式裡,大部分瀏覽器將 class/id 選擇器視為區分大小寫,以符合嚴謹的 DOM 行為。然而在怪異模式下,許多瀏覽器採用了寬鬆策略:class 和 id 名稱不區分大小寫。這意味著,如果你的 HTML 標記寫的是
,對應的 CSS 用 .myclass { color: red; },在標準模式下樣式不會套用(因為 "MyClass" 與 "myclass" 不同);但在怪異模式下,瀏覽器會視它們為相同名稱,段落會被正確套用紅色樣式。這種差異是為了相容早期製作者可能未嚴格匹配大小寫的情況。在怪異模式下,瀏覽器乾脆「替你」忽略大小寫差異,確保樣式能作用。
CSS規則寬容度
為了迎合舊碼,怪異模式對於CSS語法的錯誤或非標準用法更有包容性。一些在標準模式下會被忽略或視為錯誤的寫法,在怪異模式中可能照常生效。例如,怪異模式允許 CSS 中使用沒有單位的長度值(在某些屬性上會被當作像素處理),接受不以 # 開頭的顏色值字串,甚至容忍行內樣式裡用大括號 {} 包裹內容的奇怪寫法等等。又比如,過去 HTML 元素
元素預設樣式與其它奇聞
怪異模式與標準模式在瀏覽器內建樣式上也有一些細微不同。例如,標準模式下表格文字繼承父元素字體大小,怪異模式曾經不繼承而使用默認值,導致表格內文字尺寸異常(新版瀏覽器已統一此行為,但早年確有其事)。又如,在標準模式,給某些行內元素(如 , 等)設定寬高是不起作用的,因為這些元素本來就不該有明確的盒子尺寸;但在怪異模式下,早期 IE 允許對行內元素設置寬高並生效,彷彿把它們當作區塊來處理。因此你可能會看到怪異模式中一個行內元素莫名其妙地就按照 CSS 設定的高度撐開了背景。再舉一例,標準模式下可以用 margin: 0 auto 讓區塊水平置中,而在早期IE的怪異模式中這招不管用(需要靠 text-align 等替代方案)。瀏覽器在現代的怪異模式中通常也維持了 margin:auto 置中的不可靠,以防老頁面布局跑位。以上種種,我們可以發現怪異模式其實集合了各種舊時代瀏覽器的Bug與特例,彙成一套「怪癖全集」。幸運的是,隨著瀏覽器演進,大多數怪異行為已在標準模式下被修復,而怪異模式只在特定情況下觸發;日常開發中如果遵循標準,就不必經歷這些亂七八糟的問題。
近標準模式有何不同?
前面提到,近標準模式其實與全標準模式幾乎一樣,僅保留很少的怪異行為。具體來說,在大多數瀏覽器裡,近標準模式只維持了「行內元素高度/表格單元格高度計算」的一點差異。例如,在標準模式下,一個只包含圖像的表格儲存格可能因為默認基線對齊而比圖像高出幾像素,但在近標準模式中,瀏覽器會套用舊規則使該儲存格高度緊貼圖像高度,沒有額外空隙。這原本是為了照顧舊網站上常用的排版手法(利用單元格與圖片製作像素精準的版面)。除了這種罕見情況,近標準模式與標準模式沒有本質區別。因此如果你看到"接近標準模式"這個詞,不必太緊張——當前幾乎所有新頁面都不會刻意觸發它,它更多是作為對歷史的兼容而存在。
總而言之,標準模式追求嚴謹精確,讓你的頁面依照現代瀏覽器統一的標準呈現;怪異模式則充滿妥協與奇葩,重現舊式瀏覽器的各種非常規行徑。了解兩者差異,能幫助我們快速定位由模式差異引發的BUG,對症下藥。
主流瀏覽器實踐:解析行為與兼容性比較
Chrome 與新 Edge (Blink 引擎)
Chrome 和基於 Chromium 的 Edge 採用 Blink 排版引擎,在渲染模式方面兩者表現等同。一旦檢測到有效的 DOCTYPE,Blink 引擎就使用標準模式,全盤按照最新標準解析;反之則進入怪異模式,套用經標準化的一組怪異行為。Blink 的怪異模式實作其實與 Firefox、Safari 非常相似,只保留必要的非標準行為。例如,它會使用傳統盒模型計算元素大小、容忍舊屬性等,如我們前節所列。Google 团隊也參與了 WHATWG 的 Quirks Mode 標準制定,確保 Blink 引擎的怪異模式與其他引擎相容。因此在Chrome/Edge中,除了一些極為細微的實現差異,開發者可以認為標準模式和怪異模式的差別行為上是一致的,且跨這兩款瀏覽器沒有明顯差異。需要注意的是,Edge 在轉用 Chromium 之前(俗稱「舊 Edge」)曾使用自家的 EdgeHTML 引擎,其對怪異模式的支援也與Chrome類似,沒有像老IE那樣複雜的多重文件模式。因此無論是在 Chrome 或新版 Edge 瀏覽器中,只要 DOCTYPE 正確,你就幾乎可以高枕無憂地享受標準模式的行為一致性。
Firefox (Gecko 引擎)
Firefox 是較早嚴格實現標準模式/怪異模式區分的瀏覽器之一。早在 Mozilla 瀏覽器年代 (約2002年) 就引入了怪異模式和「接近標準模式」的概念。Firefox 的 Gecko 引擎在標準模式下遵循各項W3C規範,在怪異模式下則啟用一系列「怪異模式補丁」,以模擬舊版網景和IE5的行為。例如 Gecko 在怪異模式中也使用傳統盒模型、容忍大小寫不敏感的選擇器、允許 document.all 這種非標準DOM介面存在等等(document.all 原本是 IE 獨有的東西,在標準模式下 Firefox 是未定義的,但在怪異模式會偷偷提供一個假的 document.all 以免某些老網站腳本報錯)。Firefox 的怪異模式實作清單曾經由 Mozilla 官方文件詳細列出,可見其內容之繁雜。不過隨著Web標準統一,Firefox 也和Blink一樣,只保留與兼容性息息相關的怪異行為。值得一提的是,Firefox對「近標準模式」的處理在早期比較獨特(主要在該模式下調整表格/圖片的高度計算,如前述),而現在這點差異也被標準化,成為所有瀏覽器的共同行為。因此在現代 Firefox 中,一樣遵循「有doctype則標準、無doctype則怪異」的原則,其呈現效果與Chrome等大同小異。開發者幾乎不需要再為Firefox寫特殊的CSS Hack——只要遵守標準,Firefox 的標準模式行為與其它瀏覽器相當一致;而在怪異模式下,Firefox 所實現的也正是那些對老網站 "必要且充分" 的怪異。
Safari (WebKit 引擎)
Safari 的核心是 WebKit,引擎原本由KDE的KHTML發展而來。WebKit 與 Mozilla 相似,實作了一套精簡的怪異模式行為。蘋果的開發者曾公開表示,WebKit 中的怪異模式只保留有限的非標準行為,並不會像舊版 IE 一樣「沉迷過去」。例如,WebKit在怪異模式下同樣使用傳統盒模型、允許某些已廢棄HTML屬性生效,但大多數現代功能依然可用,只是遇到和舊頁面衝突的地方才做特殊處理。Safari 與 Chrome 在處理模式上也非常接近——事實上早期 Safari 和 Chrome 都基於 WebKit,所以在怪異模式細節上幾乎沒有不同。需要注意的一點是,Safari 在 macOS 上還存在一個特殊的「Dashboard 偵測模式」,這是為了相容 macOS Dashboard 小工具而設計的超怪異模式,帶有比一般怪異模式更多的瀏覽器私有 quirks。但這與一般網頁無關,提及只是趣聞。總的來說,Safari 在標準模式下與其他瀏覽器並無二致,在怪異模式下所表現出的差異也遵循著業界共同約定。開發者不用特別為Safari的怪異模式做兼容,只消避免讓Safari進入怪異模式即可。
Internet Explorer (Trident 引擎) 及其遺產
雖然題目重點是現代瀏覽器,但講到怪異模式就不能不提IE的影響。老版 Internet Explorer 在處理模式方面相當特立獨行。以 IE6-IE9 為例,它們不僅有標準/怪異兩種模式,還因對舊版IE的兼容需求,衍生出了所謂「IE7標準模式」、「IE8標準模式」等多種文件模式!也就是說,IE 瀏覽器曾內建多個渲染引擎版本,新版IE會根據頁面DOCTYPE或者特定的 X-UA-Compatible 設定來切換使用哪種模式,導致一款IE瀏覽器裡暗藏著IE5、IE7、IE8等多個靈魂。其複雜程度遠超其他瀏覽器。不過隨著IE退出歷史舞台,我們不需深究。只要知道:IE的怪異模式基本等同於「IE5.5模式」,也就是保留IE5時期的所有怪癖(包含那時的BUG)。這和Firefox/WebKit那種"有限怪異"理念截然不同——IE在怪異模式下幾乎凍結了自身功能進化,以至於連一些IE後來版本修正的bug,在怪異模式中都會還原出來!好消息是,現代的 Edge 瀏覽器已經不這樣做了;壞消息是,如果你真的需要相容遠古的IE,只能祈禱老天保佑,或者使用IE瀏覽器內建的企業模式/相容模式來模擬舊版IE環境。整體而言,除了 IE 家族之外,當前主流瀏覽器對怪異模式的支持都是經過協調的,差別極微。而IE的遺留問題,如今僅在極少數企業內部環境或老舊系統上才需要特別處理。
小結
現代瀏覽器在標準模式下趨於行為一致,在怪異模式下也因為有 WHATWG 制定的「Quirks Mode 標準」而高度統一。開發者無需為不同瀏覽器各自定製怪異模式的對策;與其如此,不如專注杜絕怪異模式的發生。例如,確認所有頁面都有正確的 DOCTYPE,並盡量避免使用會誘發怪異模式的過時標記。下一節,我們將通過實例來具體觀察標準模式與怪異模式的差異,鞏固對上述原理的理解。
範例實作:模式差異的實際影響
怪異模式版本的 HTML 範例
首先是怪異模式版本的 HTML 範例(無 DOCTYPE):
<html>
<head>
<meta charset="UTF-8">
<title>Quirks Mode Demo</title>
<style>
.container { width: 120px; background: #e0e0ff; padding: 10px; }
.box { width: 100px; padding: 10px; border: 5px solid black; background: #aaffaa; }
.testcase { color: red; }
</style>
</head>
<body>
<h3>怪異模式頁面</h3>
<div class="container">
<div class="box">Box</div>
</div>
<p class="TestCase">這段文字應該是紅色?(類名大小寫測試)</p>
</body>
</html>
標準模式版本的 HTML 範例
接著是標準模式版本的 HTML 範例(有正確 DOCTYPE):
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Standards Mode Demo</title>
<style>
.container { width: 120px; background: #e0e0ff; padding: 10px; }
.box { width: 100px; padding: 10px; border: 5px solid black; background: #aaffaa; }
.testcase { color: red; }
</style>
</head>
<body>
<h3>標準模式頁面</h3>
<div class="container">
<div class="box">Box</div>
</div>
<p class="TestCase">這段文字應該是紅色?(類名大小寫測試)</p>
</body>
</html>
觀察結果
將上述兩個檔案分別在瀏覽器中打開,仔細比較它們的呈現:
盒模型差異: 在標準模式頁面中,綠色的 .box 區塊寬度設定100px,但由於它有左右各5px的內距和邊框,因此實際寬度超出了父容器.container(父容器寬度120px)。你會看到 .box 明顯撐出父容器的範圍,可能導致水平方向出現滾動條或溢出容器背景。而在怪異模式頁面中,.box 卻完美地嵌入父容器內,沒有溢出。這是因為怪異模式採用了傳統盒模型計算,將內距和邊框算入100px之內,所以.box的總寬度仍是100px,完全放得進120px寬的容器中。
樣式應用差異: 兩個頁面都有一段段落文字 <p class="TestCase">...,CSS 中我們只定義了小寫類名 .testcase { color: red; }。結果在怪異模式頁面,你會發現這段文字顯示為紅色,因為瀏覽器在怪異模式下不區分大小寫,將HTML中的class="TestCase"識別匹配到了CSS的.testcase樣式。反觀標準模式頁面,這段文字卻是黑色(預設字色),因為在嚴格模式下 TestCase 與 .testcase 被視為不同字串,CSS樣式沒有套用。這直接證明了我們前面提到的「class名稱大小寫敏感性」差異。
透過這個小實驗,你可以更加直觀地體會兩種模式對頁面布局和樣式解析的影響。當然,我們僅演示了其中兩點差異——實際上還有許多細節無法一一呈現在這簡單範例中。不過,有了這份體驗,你應該更能理解為何一個缺失或錯誤的 DOCTYPE 就可能毀掉整個版面:因為它會讓瀏覽器切換人格,進入另一種解析邏輯!在日常開發中,建議大家隨時檢查自己的頁面是否處於標準模式(可利用瀏覽器開發者工具或 JavaScript document.compatMode 來確認),以確保所見即所寫,不會因模式不同而陰溝翻船。
常見問答 (Q&A)
問:為什麼現代瀏覽器仍然要支援怪異模式?能不能乾脆取消它?
答: 怪異模式的存在完全是出於歷史包袱和向後相容的考量。網際網路上仍有不少年代久遠的網站,它們的程式碼遵循著上世紀瀏覽器的規則。如果瀏覽器硬生生地取消怪異模式,用標準模式去解析那些老網站,版面往往會亂得不成樣子,等於把這些網站判了死刑。為了不破壞既有網頁生態,瀏覽器製造商選擇繼續支援怪異模式,確保這些老舊內容至少「看起來」和過去一樣。幸運的是,這對於新網站沒有負面影響——只要你遵守標準寫碼,瀏覽器就不會跑去用怪異模式。因此,可以將怪異模式視為一種底層的保險機制,維繫著Web的兼容性。它或許很少用在新開發上,但對整個互聯網的延續性功不可沒。在可預見的未來,主流瀏覽器都不會輕易移除對怪異模式的支援,以免影響遺留內容。
問:我要如何強制讓我的頁面使用標準模式?
答: 非常簡單:在 HTML 檔案開頭正確書寫 DOCTYPE 即可。對於現代HTML5文件,建議使用:
<!DOCTYPE html>
這一行宣告必須是文件中的第一行(在 <html> 標籤之前,且不能被任何空白或註解擋在前面)。只要這個DOCTYPE存在且拼寫無誤,所有現代瀏覽器都會切換到標準模式。另外,如果你的頁面是以 XHTML (application/xhtml+xml) 等XML格式傳送,則天然處於標準模式;但一般而言,大多數網頁還是 text/html 格式,需要靠 DOCTYPE 來觸發標準模式。簡而言之:把 DOCTYPE 當作每個HTML的必備第一行,這樣瀏覽器就會聽你的話,用最嚴謹的模式渲染。
問:如何檢查一個網頁目前是處於標準模式還是怪異模式?
答: 有幾種簡便的方法:其一,打開瀏覽器的開發者工具(DevTools)的主控台或網路面板,在Firefox中,若頁面處於怪異模式,控制台通常會拋出警告提示你「頁面正在怪異模式渲染」;反之沒有警告多半就是標準模式。其二,你可以在控制台輸入一行 JavaScript:
console.log(document.compatMode);
如果輸出結果是 "CSS1Compat",表示當前處於標準模式;如果結果是 "BackCompat",那就是怪異模式無誤。還有一個土辦法:觀察一些容易受模式影響的佈局細節,例如前面範例提到的盒模型或一個類名大小寫不一致的樣式是否生效,都能間接說明模式。總之,document.compatMode 是最權威的指標,寫個小腳本查詢一下,一清二楚。
問:現在開發時還需要考慮怪異模式嗎?是不是應該完全避免它?
答: 一般而言,你應該盡量避免讓頁面落入怪異模式。 現代前端開發幾乎沒有理由主動使用怪異模式。一方面,標準模式提供了最一致可預測的行為,能使用最新的CSS/JS功能,瀏覽器對它的優化和支持也最佳;另一方面,怪異模式究竟只是為相容舊站點而生,裡頭充滿各種不符合標準的邏輯,對於新的專案而言只會添亂。實際開發中,除了極特殊的需求(例如你在復原一個1990年代的頁面樣貌純作懷舊用途),沒有建議使用怪異模式的情境。如果不小心誤觸怪異模式(通常是忘了 DOCTYPE 或DOCTYPE拼寫錯誤),正確做法是立即修正,而不是試圖"兼容"它——因為一旦進入怪異模式,你可能需要檢查每個元素的怪異行為,成本極高。總之,能不用就不用是對待怪異模式的最佳態度。幸好,只要堅持標準的編碼習慣(例如始終使用HTML5 DOCTYPE,避免使用過時的標籤和屬性),怪異模式完全可以在我們的開發生命中缺席。未来隨著老網站逐漸更新或淘汰,怪異模式的重要性只會繼續下降,但在那之前,好的做法就是把它關在籠子裡,不讓自己的項目陷入怪異模式。
問:所謂「近標準模式」值得關注嗎?我需要特別去觸發或避免它嗎?
答: 對於絕大多數開發者而言,近標準模式幾乎可以忽略不計。它出現於一些歷史遺留的 DOCTYPE 情況下,比如使用 XHTML 1.0 Transitional 或 HTML4.01 Transitional 且包含系統識別碼的DOCTYPE,Firefox、Safari等就會進入近標準模式。但如果你遵循目前的最佳實踐——一律使用簡潔的 HTML5 DOCTYPE——那你壓根不會碰到近標準模式。從行為上看,近標準模式與標準模式只有非常細微的差異(主要影響表格中純圖片單元格的高度計算,如先前提及)。在日常布局或功能實作中,這點差異幾乎感覺不出來。因此你無需「特別支持」近標準模式;只要你的頁面是有效的HTML5頁面,它就默認處於標準模式,和近標準模式不會有交集。如果好奇想測試近標準模式,可以嘗試使用 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> 這樣的老DOCTYPE來載入頁面,Firefox 之類瀏覽器會以近標準模式解析,但再強調一次,這純屬學術探討,實務開發中沒有必要這麼做。我們只要確保使用正確的DOCTYPE,專注於標準模式的表現即可。
總結
希望這篇指南讓你對標準模式與怪異模式有了全盤的了解。掌握這些差異能幫助你快速診斷那些令人困惑的跨瀏覽器問題,也更珍惜良好標準習慣的重要性。總而言之,以標準為本,怪異為輔:讓怪異模式留在過去,我們則昂首邁向現代Web的美好未來!祝每位開發者都能寫出既符合標準又兼容性的優質網頁。Happy coding!
