武林網(www.companysz.com)文章簡介：Web開發人員可以通過創建CSS類及id名稱并使用這些名稱來對divs以及其他的格式頁面元素進行標識。對開發人員來說，在命名重新定義XHTML標記（tags）的CSS selectors時，必須保證其與預定義的標記準確匹配，但就類以及id選擇器名稱而言，則仁者見仁，智者見智。然而隨心所

Web開發人員可以通過創建CSS類及id名稱并使用這些名稱來對divs以及其他的格式頁面元素進行標識。對開發人員來說，在命名重新定義XHTML標記（tags）的CSS selectors時，必須保證其與預定義的標記準確匹配，但就類以及id選擇器名稱而言，則仁者見仁，智者見智。然而隨心所欲的為這些類以及id命名則并不是個好的習慣。

在閱讀了由Andy Clarke（of Stuff and Nonsense and All That Malarkey）以及Eric Meyer所撰寫的關于CSS類以及id命名規范的系列文章之后，我開始思考在自己的Web站點設計過程中對類以及ids的命名方式。

直觀命名

當在設計Web頁面以及需要對一個div進行標識的時候，最自然的想法就是使用可以描述元素所在頁面位置的詞匯來對其命名。這種方法使得類以及id的名稱如下面所示：

top-panel

horizontal-nav

left-side

center-column

right-col

這些是CSS以及XHTML類和id的有效命名方式。這些詞匯簡單并且能夠使人顧名思義，因此滿足了標識頁面元素以及相應的CSS樣式的需要。

但問題是這樣的名稱同頁面內容的特定表達方式相關聯。這些命名參考了某種特定頁面布局中的頁面元素位置，因此在這樣的布局之外使用就會顯得不合適甚至造成理解混亂。同時，這些命名沒有涉及文檔內容的結構。因此，下面給出了對CSS類以及ID命名更好的方法。

結構化命名

結構化的標記意味著表達方式/位置信息同內容的完全分離——這其中包括出現在標記（markup）中的類和id名稱。

有標記的相關信息都是用來描述文檔的結構而不是外觀。這樣的特點使得我們可以通過簡單的改變CSS的方式來對不同外觀格式下的內容（content）以及標記（markup）進行重用。當你理解這種方式時，很容易就可以發現采用頁面位置來為類以及id命名的方式在處理如音頻（audio）等外觀格式上顯得非常不合適。因此，應當根據在文檔中的使用目的而非出現位置來對類以及id進行結構化命名。

可以按照如下所示的結構化方式來對類以及id名稱命名：

branding

main-nav

subnav

main-content

sidebar

這些名字同直觀命名方式一樣非常易懂，但他們描述了頁面元素的作用而非位置。這使得代碼更加符合使用純粹的結構化標記（structural markup）的初衷，即開發人員可以在不改變標記的情況下對各種各樣媒體下的顯示格式進行處理。

即使你不打算在其他的媒體上對Web頁面進行格式修改，使用結構化命名方式還可以幫助你在日后的站點升級或重新設計中更為輕松。例如，結構化命名避免了當一個div同id right-column移動到頁面左邊后所帶來的混亂。對div sidebar的采用這樣的命名方式就顯得更加適當，因為無論它出現在頁面的哪一邊，這個名字仍然對開發人員來說直觀易懂。

慣例

Andy Clarke分析了40份由推崇標準化Web設計理念的開發人員所設計的Web站點的源代碼。盡管類以及id名稱很不統一，但是還是發現了一些頻繁出現的常用名稱。這里給出了最常用類/id名稱的示例列表：

header

content

nav

sidebar

footer

如果要查看完整的列表，可以看看最常見命名慣例表

這些常見的類以及id名稱是否標志著一種標準的誕生或是普遍接受慣例的形成呢？盡管這是我所希望的，但我并不這么認為。我的確希望能夠看見一整套對于我們每天都可以看到的常用頁面元素的命名標準。同時，使用標準化的命名方式可以使得尋找頁面元素以及對Web站點升級帶來方便，尤其當需要在由不同開發人員在不同時間所開發站點中換來換去工作的時候。