web設計與開發常見錯誤


本文包含了常見的設計開發錯誤以及我的一些解釋,我也嘗試着提供一些避免錯誤的方法,在某些問題上我也會給出錯誤信息的鏈接。

  • 混淆文檔類型(DOCTYPE)

  • 完全不寫、寫的不正確、或放錯地方。我曾見過HTML 4.0 Transitional被用在XHTML網頁和框架頁中,還看到過在開頭的<html>標籤後寫DOCTYPE聲明和一些不完整的聲明。

  • 爲什麼?有兩個原因。首先,文檔聲明是必須的,在W3C HTML 4.01 specW3C XHTML 1.0 spec裏 都有說明。第二,瀏覽器會根據指定的文檔類型去顯示和渲染網頁。也就是“DOCTYPE切換(DOCTYPE switching)”。爲了保持各個瀏覽器顯示網頁的一致性,特別是你用了CSS,你一定會希望瀏覽器使用它們“Standards compliance mode”。關於DOCTYPE切換,可以看看使用正確的DOCTYPE!正確的文檔類型聲明,正確的佈局方式

  • <span>癖

  • 樣式化的一個常見方法就是把一段東西用<span>標籤圍起來,並且帶一個class用來設置樣式。我敢保證你經常可以看到諸如<span class="heading"><span class="bodytext">的代碼。

  • 爲什麼? 其實在很多情況下這完全沒必要,這樣做只會混亂標籤並且沒有什麼語義。標題就用標題(h1~h6)標籤,段落就用段落(P)標籤,列表就用列表(UL, OL和DL)標籤。然後再用CSS去樣式化,如果需要的話,也可以加class和id屬性。

  • 太多可視化思考

  • 以爲web就是WYSIWYG(所見即所得) – 一開始就想着這些東西該怎麼表現的,而不是先去考慮邏輯結構上怎麼樣。

  • 爲什麼? 雖然大部分網民都是視力正常的,但是還是有殘疾人上網的。網民可能使用不同瀏覽器、不同系統、不同尺寸顯示器和分辨率、不同的窗口大小、不同顏色標準和文字大小,所以你不應該把你的網頁做成WYSIWYG。網頁不是印刷品或者電視節目。要讓你的設計彈性化。

  • 缺乏語義

  • 沒有使用具有語義的標籤。想當然的按照圖形瀏覽器渲染的HTML樣式去寫代碼,而不是參照這些標籤的意義

  • 爲什麼?和上文提到的"<span>癖”比較接近,沒有好好的利用現有的HTML標籤來表達它應該表達的語義。沒有語義化的HTML,爲那些非可視化用戶代理(UA)造成了理解上的困難。而且語義化的HTML很容易進行CSS樣式化。

  • 編碼不一致

  • 在服務器發送的默認編碼是一種而文檔裏面又使用另外一種,這可能會造成瀏覽器亂碼(不正常顯示)。

  • 爲什麼?因爲你必須得保證所有你的訪問者都能閱讀你的內容。

  • 不正確的alt屬性

  • 沒寫或者寫了沒意義。在網絡上可以看到非常多沒有alt屬性的<img>標籤。沒意義的alt屬性倒是不如前者常見,比如“spacer GIF used to make the layout look good”,“帶有陰影的藍色原點”, 以及“JPEG圖片,123 KB”。要記住,alt屬性在<img><area>裏是必須的。

  • 爲什麼? 這是必須的,沒有alt,任何圖片中的信息就會被屏幕閱讀器、文本瀏覽器、搜索引擎機器人忽略,或者用戶關了圖片顯示就會顯示爲X。注意圖片的alt的文字是要相關的,不要給裝飾性的圖片或者用來佈局的圖片加alt屬性值,指定一個空值就可以了,如alt=""

  • 不合法的id和class屬性

  • 在同一頁面裏使用了多次同一id,以及在idclass和CSS選擇器中使用了非法字符。

    對於CSS來說 (CSS 2.1語法和基本數據類型):

    在CSS 2.1裏,標示符(包括元素名、class和ID)只能由數字、字母、ISO 10646通用字符集U+00A1及更高、連接線("-")、下劃線("_")組成,並且不能以數字開始。

    對於HTML (HTML基本數據類型):

    ID和NAME必須以大寫或小寫字母開始,隨後可以接任意字母、數字、連接線("-")和下劃線("_")、冒號(":")和分號(".")。

  • 爲什麼?遵循以上標準的瀏覽器可能不會按照你預期的現實。如果一個頁面中有多個重用的id值,那麼任何使用了該值的JS就可能會失效或者錯誤。

  • 瀏覽器探測

  • 使用服務器端或客戶端的腳本測試訪問者的瀏覽器,然後發送或者執行特定瀏覽器的代碼。這對於最新的瀏覽器、更新過的瀏覽器或者具備欺騙功能的UA(比如Opera默認僞裝成IE)。

  • 爲什麼?增加了不必要的麻煩,並且最終會失效

  • CSS缺少單位

  • 長度值(水平和垂直的)需要單位,除非當該值爲零時。不像在HTML裏面,可以輸入width="10"。在CSS裏, 必須寫成width:10px;(或者其他單位)。

  • 爲什麼?在遵循規範的瀏覽器中會被忽略。

  • 瀏覽器特定的CSS

  • 樣式化滾動條、表達示和濾鏡等,都只能在IE下工作。這也不合法。

  • 爲什麼? 只在特定的瀏覽器裏面正常。如果你真的必須使用IE特定的CSS,可以單獨寫一個CSS文件並且使用條件註釋,或者保證只有IE能看到那些不合法的CSS。

  • JavaScript依賴症

  • 網站整個依靠JavaScript。很多人都願意使用不支持JS或者禁用JS的瀏覽器。當前的情況(W3Schools瀏覽器統計, TheCounter.com)表明至少有8%-10%的用戶瀏覽器不支持JS。搜索引擎機器人對待JS也不是非常友好,雖然有報告說Google正在開發支持JS的機器人。如果你的站點需要開啓JS才能導航,那別指望有一個很高的搜索引擎排名。

  • 爲什麼?對搜索引擎不友好,難以提高排名。

  • Flash依賴症

  • 實際上並不是所有人都裝了Flash Player插件。並且大部分搜索引擎機器人都不支持Flash(Google有報告稱已經在嘗試索引Flash文件,但是他們還是要求你的內容和導航寫 在HTML裏),所以如果你整個網站或者導航部分是Flash的,你的網站一般就不會得到很高的PageRank。

  • 爲什麼?搜索引擎不友好,但這並不是說你應該放棄Flash,只是你應該使用的比較有技巧。

  • JunChen注:爲Flash建立搜索索引,可以參考flash 8 swf metadate應用

  • 文字做成圖

  • 把文字做成圖,又不提供更多提示信息。這不僅僅增長了訪問者下載時間,也不利於訪問者選擇和複製文字,又不利於文字放大。

  • 爲什麼?不親切,增加下載時間,對搜索引擎不友好。

  • 不友好的表單

  • 沒有語義、難以使用的表單。要學會使用<label>標籤,<fieldset><legend>標籤,不要使用“Reset”按鈕

  • 爲什麼?沒有語義並且難以使用。閱讀設計易用的表單優秀、易用的表單,和重設和取消按鈕,看如何設計友好和易用的標單。(JunChen注:使用Reset按鈕會增加用戶思考的時間,並且誤按情況屢屢發生)

  • 過時的HTML

  • 多層嵌套的表格,透明的spacer圖片,<font>標籤,表現層的標籤。其實這個大家都已經知道了。

  • 爲什麼?增加複雜度,讓整個頁面代碼臃腫冗餘,不易理解,對搜索引擎不友好。

  • 一切向IE看齊

  • IE優先,做完了再看看其他瀏覽器裏如何,有問題再調整。

  • 爲什麼?浪費時間,並且這個習慣不好。IE會默認接受很多錯誤的代碼,所謂“容錯性”。而其實IE也接受良好結構的HTML,並且在其他瀏覽器裏都正常,這也不會浪費很多時間。更多信息看IE真相

  • 不合法的HTML屬性

  • 使用不推薦的屬性或者只能在特定瀏覽器裏生效的屬性,諸如marginwidthleftmarginlanguage,給<table>height,給<img>border等等。

  • 爲什麼?不合法並且沒必要。你可以使用CSS。對於<script>標籤,使用 type,而不是language,來指明腳本語言(一般是JavaScript)。

  • 沒有編碼的“&”

  • 很多URI帶有變量和沒有編碼的“&”符號。這不正確,並且可能會造成很多問題。 “&”符號必須要寫成&amp;

  • 爲什麼?“&”符號和驗證一文中可以找到解釋和一個會引起錯誤的例子。

  • 框架

  • 使用框架來分割瀏覽器窗口並且加載數個獨立的文件。

  • 爲什麼?首先我要說的是,框架可能比較實用,前提是你正確的使用了,比如說在內聯網和一些web應用程序中。 而對於一個網站來說,框架有很多易用性和可用性方面的問題。比如加入收藏夾的問題、打印問題以及鏈接問題,並且對搜索引擎不友好。因爲機器人在多個框架頁 裏面工作比較有問題。

  • 數據表格的誤用

  • Table本來就是用來放置表格狀的數據,不能像佈局表格一樣去寫,而是可以用很多自帶的標籤和屬性來使表格結構化和語義化。

  • 爲什麼?屏幕閱讀器和其他輔助技術在閱讀這些錯誤的數據表格時會有問題。很多文章都介紹瞭如何寫出結構化的數據表格,如Web Standards Project的A table, s’il vous plat

  • Divitis和classitis

  • 相對於<span>癖,Divitis和classitis就是用了太多不必要的Div和class。

  • 爲什麼?參看“<span>癖”和“缺乏語義”部分。

  • 過寬的固定寬度

  • 如果你使用的是固定寬度的佈局,請不要設定的過寬。說明:在這裏我並不是說固定佈局和浮動佈局孰優孰劣。

  • 爲什麼?如果你指定的寬度寬於瀏覽者的屏幕,就等於強迫出現水平滾動條,那極不友好。

  • 含糊不清的和帶表現含義的class、id名

  • 如何給classid命名,取決於它是幹嘛的而不是它看起來像什麼、在哪裏。

  • 爲什麼?爲了避免你重新設計時候容易產生的混淆。比如一個名爲largeblue的class,你卻用來用來讓字變得“小”和“紅”,一個名爲leftcol的id你卻用來顯示在右邊。

  • 沒有背景色

  • 沒有給body指定背景色。

  • 爲什麼?很多用戶會把瀏覽器設置成其他的背景色,如果你不寫明的話。

  • 非良好結構(well-formed)的XHTML

  • 使用非良好結構(well-formed)的XHTML。

  • 爲什麼?如果XHTML被服務器伺服爲application/xhtml+xml,嚴格的瀏覽器,如Mozilla系列,就不會顯示那些非良好結構的XHTML。說明一下,本網站並沒有把所有望也伺服爲application/xhtml+xml,理由我在另外一篇文章裏說明:Content negotiation.

  • text input顏色設定遺漏

  • 只給表單區域指定背景色或者文字顏色,特別是當行或多行文字域(input type="text"textarea)。

  • 爲什麼? 有些人把他們的瀏覽器或操作系統設置成反色,默認情況下一個text input就會顯示爲黑底白字,而不是你想要的白底黑字。

    如果你把文字顏色設置成深灰色,又不指明背景色,在反轉了顏色的瀏覽器中,就會顯示爲黑色背景的深灰色字,一團糟。反之同理。

    總記住設定前景和背景色,或者記得要設定文字輸入域。

這些都是你應該要注意的問題,很長?如果你都避免了這些錯誤,那麼你已經做得很好了。如果你已經犯了其中的一個或多個錯誤,嗯,我真覺得有點內疚。最後希望本文能夠幫助你在以後的工作中少犯錯誤。

      仿StackOverFlow的國內站正在成長,國內的問題解決論壇需要大家出一份力!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章