W3C validation有時難以操作，但用它你能夠檢查由版面規(guī)劃引起的差錯。驗證程序拋出許多差錯和正告，說明你的XHTML沒有完善，可能無法在不同瀏覽器上保持一致功用。下面十個纖細的失效問題難住了大批程序員，咱們告知你怎么處理。在本文開端前介紹一些運用W3C驗證程序時需要注意的問題。

 

　　不要憂慮驗證程序的正告——假如驗證程序說發(fā)現(xiàn)12處過錯以及83處正告，不要理它，繼續(xù)進行下一步。

 

　　一次更正一個過錯——按次序發(fā)展工作，從上到下，一次批改一個過錯。HTML用瀏覽器從上到下瀏覽，這些過錯也是按相同次序顯示。

 

　　每次批改代碼后要改寫代碼，使它們從頭收效——一個小過錯常常會引發(fā)之后整頁的連串過錯。因此假如操作不妥，“批改過錯”也可能引發(fā)更多過錯。每次批改后使代碼從頭收效，這樣就能夠確保徹底處理問題。

 

知道了上面這些根本的異常情況，下面咱們就來看看版面規(guī)劃無效的幾個原因。

 

div 標簽未關(guān)閉

這是版面規(guī)劃失效的常見原因之一。當咱們了解到這是多少精美的版塊規(guī)劃失效的元兇巨惡時，總會大吃一驚。敞開的div標簽是遍及的版塊規(guī)劃失誤之一，也是難診斷的失誤之一。驗證程序有時會指向過錯的敞開div標簽，診斷時就像難如登天一樣費事。

費事的embed標簽

九十年代前期，Microsoft和Netscape的瀏覽器開端能夠辨認非標準的獨有字體。惋惜的是這意味著W3C驗證程序還不能辨認某些關(guān)鍵HTML 標簽，如“embed”，即使這些標簽已經(jīng)被廣泛運用。假如的確期望得到嚴厲的DOCTYPE（文檔類型）驗證，就只能拋棄嵌套。

假如一起想要收效的版面規(guī)劃和嵌入式媒體，能夠試試Flash Satay辦法。

 

不妥的DOCTYPE聲明

不聲明DOCTYPE，或許在文件開端過錯聲明DOCTYPE，也是一個常見過錯。根據(jù)一般經(jīng)驗，Strict DOCTYPE是咱們追求的第一流驗證。Strict validation標明你的網(wǎng)頁能夠在所有瀏覽器上都得到佳展示。Strict 聲明代碼如下：

 

 

結(jié)束斜線

假如你的網(wǎng)站不能驗證，很有可能是在代碼的某個當?shù)芈�寫了結(jié)束斜線。咱們很容易疏忽結(jié)束斜線之類的東西，特別是在image標簽等元素中。例如：

在嚴厲的DOCTYPE中這是無效的。要在img標簽結(jié)束處加上“/”以處理此問題。

 

 

Align標簽

假如DOCTYPE被設(shè)為Transitional，你就會運用“align”標簽，但假如要求更高一點期望得到Strict驗證，你會看到許多過錯。 Align是另一個不可用于版面規(guī)劃的標簽。能夠嘗試用“float”或許“text-align”來替代align轉(zhuǎn)換元素。

JavaScript

假如已經(jīng)聲明Strict DOCTYPE，就需要在JavaScript中掩蓋CDATA標簽。驗證程序的這一方面難倒了許多程序員，由于網(wǎng)站傾向于為廣告和追蹤腳本運用嵌入的 JavaScript。假如必須用到JavaScript，能夠在其前后加上如下標簽：

 

圖畫需要“alt”特點

你可能還沒有注意到，圖畫也是高檔驗證的潛在攔路虎。除了結(jié)束斜線，高檔驗證也要求用alt標簽來描繪圖畫，如alt= ”Scary vampire picture”.

搜索引擎也靠alt標簽來辨認網(wǎng)頁上的圖畫，所以無論怎樣加上alt標簽總是好的。

不知道實體數(shù)據(jù)

實體數(shù)據(jù)是又一個影響驗證的易犯過錯。咱們能夠考慮用恰當?shù)木幋a字符來替代“&”等符號。entire list中列出在XHTML版塊規(guī)劃中可用的恰當?shù)木幋a字符實體數(shù)據(jù)。

不良嵌套

嵌套就是元素里又包括元素，如下所示：

 

 

咱們?nèi)菀谆祀s嵌套元素的次序。例如在div標簽前啟動strong標簽，但又先關(guān)閉div標簽。這可能不會改動版塊布局，但卻會使你的版塊規(guī)劃失效。

缺少“title”標簽

盡管這看上去是一個很明顯的過錯，許多程序員（包括我自己）還是經(jīng)常會在“head”版塊中遺漏title標簽。當你看到“missing a required sub-element of HEAD”（缺少HEAD的必要子元素）時，才會發(fā)現(xiàn)自己忘記增加title標簽了。在解決驗證問題時，需要仔細檢查代碼并參考 W3C 的相關(guān)規(guī)范和文檔。