為什么這么說呢？首先，我們要了解瀏覽器是如何處理內容的。在瀏覽器中顯示的內容有 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 的配置信息。
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。問題是，這一“不包括”，就除掉了大約 90% 的瀏覽器市場啊，在我們抓狂以前，先來看看 IE 是什么處理 application/xhtml+xml 的：IE 不認得這種 MIME Type，它要么提示你是否下載那個文件，要么就把文件內容當作純文本顯示出來，反正是不可能正Ｏ允頸曇恰?/P>
這正是造成我們不得不給 XHTML 文檔標以 text/html 的原因 1，實際上，目前 Web 上 95% 的 XHTML，都是扮成 HTML 的 XHTML (包括 w3.org)，瀏覽器 (包括我們引以為傲的 Mozilla) 壓根沒有用 XML 解析器去解析那些 XHTML，而是沿用處理標簽湯的老辦法。
這個時候你會問了，在我看起來，老辦法顯示得很好啊，干嗎為此感到頭疼呢？問題正是出在“看起來”這個詞上，實際上，一些細微但是不可忽略的差別仍然存在。
用application/xhtml+xml 方式解析 XHTML 與用 text/html 方式解析的差別 下面所說的“HTML”，就是指 text/html 的解析方式；相應地“XHTML”就是指“application/xhtml+xml”的解析方式。
& 等 XML 實體要正確使用。 body 設置背景色就是給整個文檔設置了背景色，但在 XHTML 中并非如此，給 document.write() 不能在 XHTML 中使用。 總結起來就是，我們正在廣泛使用的其實是一種看起來已經 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 的優勢最重要的兩點是：
顯然，如果文檔連 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 中的事實，承認也好不承認也好，確定一個目標，然后艱難而執著地前行，大概是我們這些標準推廣者唯一能做的。
注釋新聞熱點
疑難解答
