MIME Type 引出的兩難困境-網頁設計,HTML/CSS

一切從一個糟糕的瀏覽器開始，它徹底不支持 xhtml。

　　 什麼是 mime type？

　　爲何這麼說呢？首先，咱們要了解瀏覽器是如何處理內容的。在瀏覽器中顯示的內容有 html、有 xml、有 gif、還有 flash……那麼，瀏覽器是如何區分它們，絕對什麼內容用什麼形式來顯示呢？答案是 mime type，也就是該資源的媒體類型。

　　媒體類型一般是經過 http 協議，由 web 服務器告知瀏覽器的，更準確地說，是經過 content-type 來表示的，例如:

content-type: text/html

　　表示內容是 text/html 類型，也就是超文本文件。爲何是「text/html」而不是「html/text」或者別的什麼？mime type 不是我的指定的，是通過 ietf 組織協商，以 rfc 的形式做爲建議的標準發佈在網上的，大多數的 web 服務器和用戶代理都會支持這個規範 (順便說一句，email 附件的類型也是經過 mime type 指定的)。

　　一般只有一些在互聯網上得到普遍應用的格式纔會得到一個 mime type，若是是某個客戶端本身定義的格式，通常只能以 application/x- 開頭。

　　xhtml 正是一個得到普遍應用的格式，所以，在 rfc 3236 中，說明了 xhtml 格式文件的 mime type 應該是 application/xhtml+xml。

　　固然，處理本地的文件，在沒有人告訴瀏覽器某個文件的 mime type 的狀況下，瀏覽器也會作一些默認的處理，這可能和你在操做系統中給文件配置的 mime type 有關。好比在 windows 下，打開註冊表的「hkey_local_machinesoftwareclassesmimedatabasecontent type」主鍵，你能夠看到全部 mime type 的配置信息。

　　 瀏覽器處理 xhtml 和 html 有什麼區別？

　　html 的語法過於隨意了，有許多簡寫，標記不匹配的複雜狀況，同時長期 web 發展下來積累下來了許多錯誤的用法??好比一個文檔裏徹底沒有 標記??但瀏覽器仍是得支持它，可想而知，爲了支持這些「tag soup」??也就是咱們所說的那些，亂成一鍋粥的標籤??瀏覽器要很費力地去猜想一段標記的意思，努力以用戶指望的形式表達出來。一句話說，雖然 html 4.01 容許你用語義化、結構化的、內容與表現分離的方法來書寫標記，但因爲它沿襲了 html 這種格式，使得瀏覽器對於凡是 mime type 爲「text/html」的文件，都得采用一種很是費勁的方法去處理，這對於 web 的發展是很不利的。

　　再說除了瀏覽器，還有許多其餘的用戶代理要閱讀 html：純文本的瀏覽工具、讀屏器等等。

　　創造 xhtml，很大一部分緣由正是要經過 xml 從新嚴格地規範一遍標記，讓這些用戶代理能夠以一種更簡便的方式來解析這些標記。所以，xhtml 這種新的格式，天生就要求內容的發佈者必須以嚴格的方式來標記本身的文檔。

　　固然，xhtml 對於內容提供者也有好處，此處先不展開，詳見下文。

　　 mime type 與之又有什麼關係？

　　把前兩節的內容合起來，你顯然能夠發現：一個正常支持 xhtml 的瀏覽器會根據服務器提供的 mime type 是 text/html 仍是 application/xhtml+xml 來區分獲取到的內容是 html 仍是 xhtml，對這兩種格式，分別以兩種不一樣的方式來解析文檔，後者解析起來要嚴格得多，但對於用戶代理開發者和內容提供者都有很大的好處。

　　那麼，那些瀏覽器正常的支持了 xhtml 呢？答案是 mozilla、基於 mozilla 的瀏覽器如 netscape 7 和 firefox、較新版本的 opera 和 safari 等等。但不包括 microsoft internet explorer。問題是，這一「不包括」，就除掉了大約 Array0% 的瀏覽器市場啊，在咱們抓狂之前，先來看看 ie 是什麼處理 application/xhtml+xml 的：ie 不認得這種 mime type，它要麼提示你是否下載那個文件，要麼就把文件內容看成純文本顯示出來，反正是不可能正常顯示標記。

　　這正是形成咱們不得不給 xhtml 文檔標以 text/html 的緣由 1，實際上，目前 web 上 Array5% 的 xhtml，都是扮成 html 的 xhtml (包括 w3.org)，瀏覽器 (包括咱們引覺得傲的 mozilla) 壓根沒有用 xml 解析器去解析那些 xhtml，而是沿用處理標籤湯的老辦法。

　　這個時候你會問了，在我看起來，老辦法顯示得很好啊，幹嘛爲此感到頭疼呢？問題正是出在「看起來」這個詞上，實際上，一些細微可是不可忽略的差異仍然存在。

　　 用 application/xhtml+xml 方式解析 xhtml 與用 text/html 方式解析的差異

　　下面所說的「html」，就是指 text/html 的解析方式；相應地「xhtml」就是指「application/xhtml+xml」的解析方式。

1. 這是最重要的，嚴格的 xml 解析至少要求文檔是 well-formed 的，也就是標籤要正確開閉，& 等 xml 實體要正確使用。
2. 在 html 中 是用戶所能看到的所有視域，給 body 設置背景色就是給整個文檔設置了背景色，但在 xhtml 中並不是如此，給 設定背景色的效果和給 設定的不一樣。
3. 在 html 中 css 規則中對元素的匹配是大小寫不敏感的，body 和 body 匹配的是同一個元素，但在 xhtml 中倒是大小寫敏感的。
4. 在註釋中隱藏的 javascript 腳本會被 xhtml 忽略。
5. document.write() 不能在 xhtml 中使用。
6. html dom 和 xhtml dom 的元素和屬性返回值是不一樣的，html 中是大寫，xhtml 中是小寫。
7. 還有很多其餘的 dom 問題。

　　總結起來就是，咱們正在普遍使用的實際上是一種看起來已經 xhtml 化的 html，想象一下吧，若是要求全部這些網站當即把 mime type 換成 application/xhtml+xml，即使用能夠正常解析 xhtml 的瀏覽器來瀏覽，它們多數會死在前面列舉的某一條緣由下，沒法正常顯示。然而這很差說是 xhtml 的錯，正常的處理理應如此，只不過咱們一直被縱容了。

　　但是 w3c 仍是不斷要求咱們以正確的 mime type 來提供 xhtml，爲何呢？由於咱們要用到 xhtml 提供的好處啊，只有被認爲是 xhtml 或者 xml 文檔的東西，瀏覽器纔會啓用這些「好處」，好比你能夠試着在 ie 中打開 xhtml 中嵌入的 mathml 看看，沒有效果，它被看成 html 同樣顯示。

　　如今的問題是，既然把文檔設定爲真正的 xhtml 是如此的麻煩，會帶來如此多的問題，幹嘛不舒舒服服地呆在 html 上呢？爲何要往 xhtml 過渡？xhtml 提供的「好處」值得咱們爲此付出如此多的代價嗎？

　　 xhtml 的優點

　　最重要的兩點是：

1. 除了前面討論的用戶代理易於處理之外，實際上，大量的基於 xml 的工具，許多對 xml 有很好支持的編程語言，都可以方便地解析你的文檔，從中提取出須要的信息。固然，也包括搜索引擎。
2. 你能夠利用 xhtml 繼承自 xml 的良好的擴展性，好比在 xhtml 中嵌入 rdf 數據，描述文檔的語義信息；加入 mathml 標記，描述數學公式；加入 svg 標記，使用可伸縮矢量圖型。

　　顯然，若是文檔連 well-formed 都作不到，優勢 1 對你是無效的，就算有效吧，就我的來講，其實也沒有多少人對 xhtml 進行 xml 解析，由於能作到的，大概也就是從 h1、h2 這些標記中讀出文檔結構一類的功能，實在沒什麼大用處。

　　而第二點對大多數內容提供者來講，太遠了，rdf 是什麼東東？加入 rdf 信息有什麼好處？沒多少人知道或者有興趣知道；mathml？這是可擴展性目前用得最多的地方，由於不少 mathml 閱讀和編輯工具已經普及了，但若是你不是個整天在公式中打轉的科學工做者，多半對此也沒有興趣；svg 呢？卻是挺有意思，但目前顯然沒有得到普遍的應用，事實上，往後可否得到普遍的應用，還要看它能不能在與 flash 的競爭中活下來：成爲標準的東西被人拋棄也是常有的事。

　　總結起來，全部這些優勢幾乎都是一些空頭支票，一些將來才能實現甚至將來都不知道能不能實現的東西，好比說你如今在開發一個 cms 系統，若是如今都已經不能保證裏面的內容 well-formed，有什麼理由說之後，數據愈來愈多之後，反而會回頭去把錯誤的標記一一改正？

　　事實上，用不到這些空頭支票，咱們的生活幾乎沒有受到任何影響。

　　那麼，是否這就是說，xhtml 幾乎就是一個雞肋了 ？

　　 xhtml 啊 xhtml

　　行文至此，已經陷入了僵局，其實我本無心把 xhtml 說得那麼差的，但問題是我每句說的都是實話呀，也沒有忽略什麼有必要提到的因素，但反覆查考，總結起來仍是那一句話：xhtml 實際上是一個帶一點理想主義的，對普通用戶來講，相比 html 4.01 並無顯見優點的格式。

　　因而咱們就陷入了兩難困境：刨掉那些花言巧語，沒有任何顯見的優勢吸引咱們咱們轉向 xhtml，但若是咱們永遠躺在 html 4.01 舒服的被窩裏，web 豈不是永不前進了？

　　答案仍是個問號。

　　 小結

　　原本，僅僅爲了將來的錦繡圖景，你們多數仍是願意轉向 xhtml 的，這大概是個博弈論中微妙的平衡，用戶、瀏覽器廠家、標準制定者三家玩的一個遊戲，但 ie 打破了這個平衡：它不支持 application/xhtml+xml，因而用戶只好都以 text/html 來發布 xhtml 頁面。

　　若是把他們人格化：我以爲「用戶」大概是個剃頭挑子一頭熱的傢伙，他們爲本身的 xhtml 頁面在一切瀏覽器上都如此美好而感到滿意，卻渾不知道背後其實仍是 html，本身沒沾着一點「x」的好處。

　　這時標準制定者??他必定是個理想主義者??也不滿意，由於用戶其實仍是在以 html 的方式來寫 xhtml 的，根本沒準備好向 xhtml 進行轉變的決心，標準制定者一心領着你們往 web 美好的將來遠航，卻發現不管是用戶仍是瀏覽器廠商都在盡給他添亂。

　　瀏覽器廠商們??他們擁有最大的籌碼，卻始終冷眼旁觀??此時卻在開心地內鬥，對此狀況聳聳肩表示無能爲力。

　　你可能會對此感到沮喪，但這的確是目前 web 中的事實，認可也好不認可也好，肯定一個目標，而後艱難而執著地前行，大概是咱們這些標準推廣者惟一能作的。

　　 註釋

1. 也並不是徹底沒有辦法，對於用 php 或者 asp 這樣建立的動態內容而言，經過檢測 http 頭來進行內容協商是最好的辦法：給 `accept: ` 中包含了 `application/xhtml+xml` 的請求提供 `content-type: application/xhtml+xml` 的數據，而給其餘的請求提供 `text/html` 的數據。(在 456 berea street 的一篇文章詳細解釋了這種方法，實際上，打開 mozilla/firefox 的 `about:config` 頁面，你能夠找到相關的配置 `network.http.accept.default` 來驗證一下 mozilla 是否發送了正確的 http 頭。)，這幾乎是一種完美的方法了 (實際上靜態內容大概能夠經過 web 服務器的內容協商功能實現這種提供方式)，但考慮到本文主要的目的是探討是否應該用 xhtml，因此不在正文中詳細討論。
2. 仍舊是指對普通用戶而言，事實上必須認可，xhtml 的出現對於整個 web 自己的長遠發展絕對有好處。
3. 其實話不應說得那麼絕，應該說 xhtml 的出現是絕對有必要的，但其帶來的好處絕大部分是對 web 自己的，長遠的，如今難以看出的好處，對用戶或者開發者的好處微乎其微。