web開發者（也就是您）可以通過建立css類及id名稱並使用這些名稱來對div以及其他的頁面元素、標籤進行標識。對開發人員來說，在命名重新定義xhtml標記（tags）的css selectors時，必須保證其與預定義的標記準確匹配，但就類以及id選擇器名稱而言，則仁者見仁，智者見智。然而隨心所欲的為這些類以及id命名則並不是個好的習慣。
在閱讀了由andy clarke（of stuff and nonsense and all that malarkey）以及eric meyer所撰寫的關於css類以及id命名規範的系列文章之後，我開始思考在自己的web站點設計過程中對類以及ids的cgibhqna命名方式。
直觀命名
當在設計web頁面以及需要對乙個div進行標識的時候，最自然的想法就是使用可以描述元素所在頁面位置的詞彙來對其命名。這種方法使得類以及id的名稱如下面所示：
top-panel
horizontal-n**
left-side
center-column
right-col
這些是css以及xhtml類和id的有效命名方式。這些詞彙簡單並且能夠使人顧名思義，因此滿足了標識頁面元素以及相應的css樣式的需要。
cgibhqna
但問題是這樣的名稱同頁面內容的特定表達方式相關聯。這些命名參考了某種特定頁面布局中的頁面元素位置，因此在這樣的布局之外使用就會顯得不合適甚至造成理解混亂。同時，這些命名沒有涉及文件內容的結構。因此，下面給出了對css類以及id命名更好的方法。
結構化命名
結構化的標記意味著表達方式/位置資訊同內容的完全分離——這其中包括出現在標記（markup）中的類和id名稱。
有標記的相關資訊都是用來描述文件的結構而不是外觀。這樣的特點使得我們可以通過簡單的改變css的方式來對不同外觀格式下的內容（content）以及標記（markup）進行重用。當你理解這種方式時，很容易就可以發現採用頁面位置來為類以及id命名的方式在處理如音訊（audio）等外觀格式上顯得非常不合適。因此，應當根據在文件中的使用目的而非出現位置來對類以及id進行結構化命名。
可以按照如下所示的結構化方式來對類以及id名稱命名：
branding
main-n**
subn**
main-content
sidebar
這些名字同直觀命名方式一樣非常易懂，但他們描述了頁面元素的作用而非位置。這使得**更加符合使用純粹的結構化標記（structural markup）的初衷，即開發人員可以在不改變標記的www.cppcns.com情況下對各種各樣**下的顯示格式進行處理。
即使你不打算在其他的**上對web頁面進行格式修改，使用結構化命名方式還可以幫助你在日後的站點公升級或重新設計中更為輕鬆。例如，結構化命名避免了當乙個div同id right-column移動到頁面左邊後所帶來的混亂。對div sidebar的採用這樣的命名方式就顯得更加適當，因為無論它出現在頁面的哪一邊，這個名字仍然對開發人員來說直觀易懂。
一些命名慣例
andy clarke分析了40份由推崇標準化web設計理念的開發人員所設計的web站點的源**。儘管類以及id名稱很不統一，但是還是發現了一些頻繁出現的常用名稱。這裡給出了最常用類/id名稱的示例列表：
header
content
n**sidebar
footer
這些常見的類以及id名稱是否標誌著一種標準的誕生或是普遍接受慣例的形成呢？儘管這是我所希望的，但我並不這麼認為。我的確希望能夠看見一整套對於我們每天都可以看到的常用頁面元素的命名標準。同時，使用標準化的命名方式可以使得尋找頁面元素以及對web站點公升級帶來方便，尤其當需要在由不同開發人員在不同時間所開發站點中換來換去工作的時候。
本文標題: 思考web站點設計對類以及id的命名方式
本文位址: /web/css/25672.html
商業Web站點設計策略
相信很大一部分人知道，我們國內的很多web站點設計專案都存在著乙個特點，那就是將設計和製作混為一談。所謂的設計站點，就是簡單的把客戶給的資料圖形化，不考慮任何其他的因素，比如能否讓站點實現預期的商業收益，讓站點真正給使用者提供他們想要的資訊和服務。於是，大量的站點形同虛設，成了白白浪費時間 金錢 人...
c 類設計思考
1 是否需要建構函式 2 資料成員函式是否需要是私有，對外隱藏 3 是否需要乙個無參建構函式 class point point going 10 4 建構函式是否需要初始化所有成員 5 需要析構函式嗎 成員是new的物件時 6 需要乙個虛析夠函式嗎。乙個父類指標指向乙個子類物件，delete該指標...
WEB應用與站點的差別以及未來發展推測
web應用與站點的差別 之所以要弄清這兩個的差別，對於網頁設計師以及參與到網際網路行業的職業，其方發展向有非常重要的意義。在曾經，訪問的站點基本上是單向去獲取。輸入 乙個 就會得到乙個頁面，在server那邊，這些頁面都是預先製作好放在空間裡供人獲取 訪問 站點的維護者須要手工處理非常多事物。直到後...