命名 CSS 的類或 id 時單詞間如何連接?
css類或id命名時單詞間連接通常有這幾種寫法:
駝峰式:solutionTitle solutionDtl用-連接:solution-title solution-dtl下劃線連接:solution_title solution_dtl應該採用哪種寫法呢?選擇的時候是出於個人習慣還是有別的考慮?PS:看了下豆瓣,美團,淘寶的源碼,都是採用solution-title的寫法。
團隊習慣
- 是連字元,從語義上,感覺更符合 css 中 class 的命名含義(組合式)我翻譯的 CSSwizadry 的 CSS-Guidelines,把其中關於命名規範的部分貼過來。
命名規範
一般情況下我都是以連字元(-)連接 class 的名字(例如 .foo-bar 而非 .foo_bar 或 .fooBar),不過在某些特定的時候我會用 BEM(Block, Element, Modifier)命名法。BEM 命名法可以使得選擇器更規範,更清晰,更具語義。
該命名法按照如下格式:其中:
.block{}
.block__element{}
.block--modifier{}
- .block 代表某個基本的抽象元素;
- .block__element 代表 .block 這一整體的一個子元素;
- .block--modifier 代表 .block 的某個不同狀態。
打個比方:
這個例子中我們描述的基本元素是一個人,然後這個人可能是一個女人。我們還知道人擁有手,這些是人體的一部分,而手也有不同的狀態,如同左手與右手。這樣我們就可以根據親元素來劃定選擇器的命名空間並傳達該選擇器的職能,這個選擇器是一個子元素(__)還是親元素的不同狀態(--)?
.person{}
.person--woman{}
.person__hand{}
.person__hand--left{}
.person__hand--right{}
由此,.page-wrapper 是一個獨立的選擇器。這是一個符合規範的命名,因為它不是其它元素的子元素或其它狀態;然而 .widget-heading 則與其它對象有關聯,它應當是 .widget 的子元素,所以我們應當將其重命名為 .widget__heading。
BEM 命名法雖然不太好看,而且相當冗長,但是它使得我們可以通過名稱快速獲知元素的功能和元素之間的關係。與此同時,BEM 語法中的重複部分非常有利於 gzip 的壓縮演算法。無論你是否使用 BEM 命名法,你都應當確保 class 命名得當,力保一字不多、一字不少;將元素命名抽象化以提高復用性(例如 .ui-list,.media)。由此延伸出去的元素命名則要盡量精準(例如 .user-avatar-link)。不用擔心 class 名的數量或長度,因為寫得好的代碼 gzip 也能有效壓縮。
完整譯文:http://yukir.net/CSS-Guidelines/
首先定個性,這是個純粹的「代碼風格」問題。什麼是「代碼風格」問題?有一些特徵:
1、技術規範不會硬性規定。雖然規範有時可能會提供指導性的建議,或者有時會有行業大牛出來鼓吹最佳實踐。2、個性化十分明顯。也就是蘿蔔青菜各有所愛、公說公有理婆說婆有理,永無定論。--------------------------------------------扯完之後說一下我的習慣:我以前用下劃線:
主要原因是在編輯器中雙擊可以選中;另外自己覺得下劃線好看(純個人喜好)。除此以外可能還有一點「小白式謹慎」(避免與 CSS 屬性名/值弄混、避免與減號弄混),或者我的啟蒙教材就是使用下劃線的。現在主要使用連字元:後來逐漸接手或參與了一些別人的項目,接觸過各種代碼風格。在老外的一些項目中接觸到大量的使用連字元的命名,看多了感覺也不難看。在編輯器中也可以通過雙擊並拖動來選中,所以就逐漸過渡到了連字元。在特殊場合用駝峰式:駝峰式寫法輸入不方便、引入了大小寫的複雜度、可讀性無優勢,因此很少在日常開發中使用。而正因為如此,我目前主要在一些框架級的類名中使用,以便於日常開發的命名習慣區分開,避免無意中污染框架級樣式的可能性。--------------------------------------------最後,看了 @張克軍 的答案,我並不贊同。因為「follow 標準」一說沒有根據,而且邏輯不清。(我們很容易理清一件事——給元素的 class 和 id 命名,本質上是給 HTML 標籤的 class 與 id 屬性寫入值。HTML 標籤的屬性值的合法性與 HTML 標籤屬性名、CSS 屬性的名/值的命名習慣有關係嗎?)說到「標準」,其實我也完全不知道 class 和 id 的合法值是什麼、不知道下劃線是否合法,甚至記不太清楚 class 與 id 的值是否是大小寫敏感的。為此,我查閱了現行規範 HTML 4.01 和 CSS 2.1 的部分章節。CSS 2.1 是這樣說的:In CSS, identifiers (including element names, classes, and IDs in selectors) can contain only the characters [a-zA-Z0-9] and ISO 10646 characters U+00A0 and higher, plus the hyphen (-) and the underscore (_); ...
也就是說,用下劃線來連接多個單詞作為 class 或 id 的值,是合法的。
目前我們團隊都統一使用-
- 易讀
- 易於輸入,駝峰和_都需要shift作為修飾鍵
- 和html、css的部分屬性名統一,比如data-*,background-color等
CSS 命名用 連字元(中劃線)「-」,沒有其他,不要問我為什麼!不要把碼農的思想強加到面向設計的 CSS 身上!
雙擊選中是編輯器的問題,不要因為這個就不用連字元(中劃線),XD2013年9月29日 更新:
1. 從語義化角度和保持CSS命名風格的一致性,我傾向選擇連字元「-」,CSS2.1 之前的規範語法存在錯誤,導致不能使用下劃線「_」。
2. 為什麼說這是編輯器的問題?最近發現在 Sublime text 2 的全局配置文件「Preferences.sublime-settings」中找到「Characters that are considered to separate words」,刪掉其中的「-」即可雙擊選中連字元。html和css語法中,無論是屬性名和值,用到連接符的地方都是"-"沒有「_」。follow標準有益無害。多年前似乎有說法,某些渲染引擎解析含「_」的值上會有問題,我沒碰到過。
駝峰不好,區分大小寫平添煩惱。個人認為用「_」的人唯一的可能就是團隊的約束還有下劃線可以DW雙擊選中
個人更傾向於用"-",可讀性更好。駝峰基本不用,在JS命名變數會用到我猜是習慣吧,其實和後端語言有些關係。PHP和Ruby的命名方式都是下劃線式:solution_title (PHP有些亂),而Javascript, Java都是camelCase樣式。也許不同的後端語言也會有些影響,我個人用下劃線式,因為希望前後端保持一致。當然,關鍵不在於哪種樣式,而在於團隊統一。
個人習慣,常用「_」。主要是在編輯器中雙擊能夠選中該詞,而「-」只選詞的一部分。有時候想一下,需要頻繁選中全詞,大概是因為自己對class的重用率不高所致。而習慣用「-」的大概流露出模塊化的意思。
個人的習慣是參照其本身,htmlcss參照font-family,用-。js參照getElementById,用駝峰法。類似的,php用下劃線。。。
其實這種問題還真是沒多大意義,團隊統一,自己用著舒服不就行了?
約定大於設計,
團隊約定好命名規範比去討論各個命名方式更重要。
class名用:連字元(solution-title);
id命名:駱峰式命名法(CamelCase)
只要統一規範就可
- -的好處在於css裡面比如"background-image"都是用連字元
- _的好處在於js裡面_可以存在於變數名
id/name用駝峰(_輔助,比如帶數字的id/name),class用-連字元,其實用什麼無所謂,重在統一。
獸妖題
我是個實用主義者我推薦駝峰式:solutionTitle solutionDtl下劃線連接:solution_title solution_dtl原因:這兩種方式在絕大多數文本編輯器中可以通過雙擊選中所有文本
而 「用-連接」 不能。我個人都是使用駝峰式。
團隊約定吧,class我都用連字元來連接兩個層級關係的語意,如果是用多個單詞表示一個層級,則用駝峰 類似: module-myName
如果沒記錯的話,我當初學css的時候,w3c推薦的是solution-title這種寫法。但是,大部分人都比較習慣用駝峰式,因為和js的寫法一樣,比較方便。
每個前端工程師的規範都不一樣,比如騰訊的,有些產品是駝峰式,有些是"-",有些是"_",各種不統一。。這視乎一系列產品的規範性,最好統一,這樣維護起來才比較輕鬆、方便,還有各種舒適
class名用:連字元(solution-title);id名用:下劃線(solution_title);js變數名用:駝峰法(solutionTitle)。這樣怎麼樣?
對於我來說,solution-title 與 solution_title 的區別就在於IED中雙擊它們時的區別。
我把-當成命名空間, ui-cardItems-icon :解釋ui組件下card列表裡面的頭像 ui 是cardItems的命名空間 ui-cardItems 是icon 的命名空間
推薦閱讀:
※overflow:hidden 為什麼能達到這樣的效果?
※關於BFC的一些觸發問題?
※CSS 中 font-size 定義的字體框(em box)大小,具體是怎麼實現的?
※css sprite中的sprite應該如何翻譯比較達意?