本文旨在對那些BEM的愛好者以及想要更好地使用它或者是想要加深對它了解的人有所幫助。
現在我是不抱有任何幻想，關于說BEM是一個很好的CSS命名規范。因為它絕對不是！我曾經很長一段時間因為它丑陋的語法規范而放棄了它。作為設計者的我不希望我的標記中出現丑陋的雙下劃線以及連字符。
但是作為構建一個邏輯性的、模塊化的用戶界面，它是比較務實的，這勝過了我的右大腦的抱怨 - “但是它不夠漂亮！！！”。我當然不推薦在起居室這種小范圍內使用這種方式，但是當你需要一件救生衣(當你遨游在CSS大海之中時)，我將會選擇這種函數形式。不管怎么說，足夠使用。這里有10個關于BEM的問題以及我處理這些問題的小技巧。
這里需要澄清一下，當你的元素嵌套兩級以及大于兩級的時候就需要使用子孫選擇器。這簡直就是我生命中的克星，我敢肯定他們的濫用就是有人對BEM產生反感的原因之一，如下所示:
Title text here
Lorem ipsum dolor sit amet, consectetur
Adipiscing elit. Pellentesque amet
正如你可以想象的，這樣的命名很快就會失控，越嵌套一個組件，類名就會變得更加猙獰以及不可讀。 我使用了一個短塊名稱 c-card 并且使用了短元素名，如 body , text 和 link ,但你能想象當你的初始塊名稱被命名為類似 c-drop-down-menu 時，就會出現失控現象。
我相信雙下劃線模式在選擇器名稱下應該只能出現一次。BEM代表 Block__Element--Modifier ,并不是 Block__Element__Element--Modifier 。 因此，需要避免多個元素級別命名。這時如果你存在多層嵌套，你可能就需要重新審視你的組件結構了。
BEM命名并不嚴格綁定到DOM上，所以后代元素有多少層嵌套并沒有關系。命名規范是幫助你識別頂層塊組件之間的關系，如這里的 c-card 。
這里我就會這樣子處理相同的卡片組件，如下:
Title text here
Lorem ipsum dolor sit amet, consectetur
Adipiscing elit. Pellentesque amet
這意味著所有的后代元素僅僅受到 card 塊的影響。因此我們可以將文本和圖像移動到 c-card__header ，甚至引入新的 c-card__footer 元素而不會破壞語義結構。
現在你可能已經注意到我在上述代碼中使用 c- ，這表示“組件”，并且形成了我對BEM類命名規范。這個想法來自于Harry Robert的 命名技巧 ,提高了代碼的可讀性。
我發現使用這些命名空間使我的代碼更具有可讀性，即使我不使用BEM，這也是一個重要的分辨點。
你也可以采用其余的命名空間，如 qa- 表示質量保證， ss- 表示服務器端掛鉤等。但是上述列表是一個很好的參照，如果你感覺還不錯可以將其介紹給別人。
你會發現這種風格在未來命名空間問題上會是一個很好的例子。
一些部件需要一個決定子元素布局的父容器。在這些情況下，我總是嘗試將布局抽象為一個布局模塊，如 l-grid ,并將其組件插入其中，如 l-grid__item 。
在我們的卡片示例中，如果我們想要生成一個具有四個 c-card 的列表，我將會使用下面所示的標記:
現在你應該對布局模塊和組件的命名空間的組合使用有了一個堅實的想法。
不要害怕使用一些額外的標記需要記憶而頭疼。沒有人會拍拍你的肩膀讓你移除 標簽的！
在一些情況下，這是不可能的。如，你的網格不能實現你想要的結果，或者說你想要一些語義化對父元素進行命名，這時你要怎么辦？對于我，根據不同場景，我傾向于選擇使用 container 或者 list 。返回我們的卡片示例，我可能會使用 […] 或者 […] 。關鍵點在于和你的命名約定相一致。
所面臨的另外一個問題是，組件的風格或者定位受其父容器的影響。關于這個問題Simurai對各種解決方案做了 詳細的說明 。這里我就告訴大家我認為最具有擴展性的解決方法。
假設我們想要我們的示例中 card__body 中插入一個 c-button 。這個按鈕已經有自己的組件，并且標記如下:
如果與其它常規按鈕組件沒有樣式區別，這里就不存在問題，我們可以如下所示直接使用:
Title text here
Lorem ipsum dolor sit amet, consectetur
Adipiscing elit. Pellentesque.
但是，當其樣式不同時如，我們想要其更小一點，或者完全是圓角，但是這些情況僅僅出現在 c-card 組件的一部分。這時應該怎么辦？
之前我說過，我找到一個跨組件最強大的解決方案:
Title text here
Lorem ipsum dolor sit amet, consectetur
Adipiscing elit. Pellentesque.
這就是BEM官方網站上著名的“mix”。但是當我參考了Esteban Lussich的一些意見之后，我卻對其改變了看法。
在上面的示例中， c-card__c-button 類試圖改變 c-button 類已經存在的一個或者多個屬性，但是是否成功取決于它們的源順序(或者特殊指明)。源代碼中， c-card__c-button 類只有在 c-button 類之后才會起作用，但是當你建立更多類似組件時就會失控。(當然你也可以使用 !important ，但是我并不推薦使用)
一個真正的模塊化UI元素應該是完全不知其父容器的 - 無論在哪里使用，效果應該是一致的。在一個組件中添加一個具有特定樣式的類，稱之為"mix"方法，違反了組件導向設計的 開/關 原則 - 即各個模塊之間應該沒有依賴關系。
最好的解決辦法就是在這些不同之處使用一個修飾器，因為你可能會發現，你會在其它地方對其復用。
即使你不會再次使用這些類，在修飾器指定特異性或者源順序，它們不會被捆綁到父容器上。
當然，另外一個選擇就是回到你的設計者崗位，告訴他們按鈕的樣式就應該和網站上其余按鈕保持一致，并完全避免這個問題......但是，這又是另一天。
最大的問題之一在于決定組件的結束與另一個組件的開始。在 c-card 示例中，你可能隨后就會創建一個 c-panel 組件，它們之間有很大的相似之處，但是又有細微的差別。
但是，你需要決定是否應該存在有兩個組件 - c-panel 和 c-card ,或者在 c-card 上應用一個簡單的修飾器對樣式進行修改。
這很容易造成過渡模塊化，使其一切變為組件。我建議使用修飾器，但是如果你發現你的特定組件的CSS文件越來越難以管理，這時你就可以終止對修飾器的使用。一個很好的指標就是，當你發現你不得不重置你所有的塊CSS以對你的修飾器進行樣式修飾時 - 這對我來說就可以生成一個新組件。
最好的辦法就是，如果你和其余的開發者或者設計師一起工作，征求他們的意見并進行討論。我知道這有點虎頭蛇尾，但是對于一個大型應用程序，明白模塊化的復用性以及什么時候需要組件是至關重要的。
這是一個普遍的問題，特別是當你對組件的活動或開啟狀態進行樣式修飾時。比方說我們的卡片需要有一個活躍狀態；所以當你點擊時，就會顯現一個漂亮的邊框樣式。這里你將如何對類進行命名呢？
這里我感覺你會有兩個選擇: 一個是獨立的狀態鉤，或者是在組件中添加一個BEM中的修飾符:
[…] […]
這里我喜歡保持一致性，使用BEM類似命名。一個獨立類的好處就是，它可以很容易的使用JavaScript在所有組件上應用通用狀態的掛鉤。當你不得不用腳本應用特定的基于修飾器的狀態類時，這就會變得有些困難。當然，這是完全有可能的，但意味著使用了大量的JavaScript腳本。
堅持使用一套標準掛鉤是有道理的。Chris Pearce 有一個已經 編譯好的目錄 ，我建議閱讀一下。
我可以理解人們對于構建一個復雜的UI界面所面臨的大量的類的苦楚，特別是他們不向每個類上添加一個標簽。
通常情況下，我會在有特殊樣式的組件上下文中添加類。我經常丟棄 p 標簽級的，除非是組件的特殊需要。
當然這可能意味著你的標記中包含大量的類，但是你的組件可以獨立化并且可以在任何地方無副作用使用。
由于CSS的全局特性，應用樣式所控制的遠遠大于組件所渲染的樣式。這種最初的心理不適性導致是值得的，相對于模塊化系統所帶來的好處。
假設我們想在我們的 c-card 組件中展示一個選擇清單，這里有一個錯誤的示范:
Title text here
I would like to buy:
這里存在幾個問題。其中一個就是我們在 section 1 部分使用的祖父母選擇器。另外一個問題就是所有應用 c-card__checklist__item 類的均被限定使用，不可復用。
這里我更傾向于將清單本身變為一個布局模塊并且清單子項目將會成為它的組件，使他們能夠在其他地方獨立使用。這里使用 l- 命名空間:
Title text here
I would like to buy:
這樣你就不用重復樣式，也意味著可以在應用的其它地方應用 l-list 類和 c-checkbox 類。這意味著多一點標記，但是方便了閱讀，封裝以及可重用性。你可能已經注意到了這都是共同的話題！
一些人認為，在一個元素上應用大量的類是很不好的，而且 --modifiers 會積少成多。就我個人而言，我不感覺這有問題，因為這使代碼更具有可讀性，可以很快明白其語義。
這里有一個應用了四個類的按鈕:
我知道這個語法不是最可視化的，但是卻是最明確的。
但是，如果這對于你來說是一個難題，你可以看看Sergey Zarouski所提出的 擴展技術 。從本質上說，我們將會在樣式表中使用 .className [class^="className"],[class*=" className"] 效仿vanilla CSS的擴展功能。如果你對這種語法比較眼熟，這是因為它和 Icomoon 處理圖標選擇是十分相似的。
使用這種方式，你的標記可能會如下所示:
我不知道使用 class=^ 和 class*= 選擇器所帶來的性能損失是否比單獨使用大規模的類大得多，但是這在理論上是一個很好的替代。我對于多類的選擇還是可以接受的，但是我感覺應該為那些喜歡選擇的人提及一下。
這個問題是Arie Thulank向我提出的，也是一個我掙扎了好久想出一個100%具體解決方案的問題。
一個例子就是在給定斷點一組選項卡的轉換，或屏幕導航在給定斷點處切換為下拉菜單樣式。
從本質上講，一個組件在媒體查詢下具有兩個不同的表現形式。
關于這兩個具體例子，我的傾向是建立一個 c-navigation 組件，因為在兩個斷點處它的行為是最基礎的。這讓我產生了一個思考，在大屏幕上如何將一個圖像列表轉換為幻燈片形式？這對于我來說可能是一個邊緣情況，并且只要是具有可行性文檔和評論，我認為這是完全合理的，為這種類型的用戶界面創建這種具有明確的命名(如 c-image-list-to-carousel )一次性獨立組件。
Harry Roberts曾寫過 響應后綴 ，這也是一種處理方式。他的做法是為了更多的布局和樣式的變化，而不是整個組件的變化，但我不明白為什么這種技術不能應用在這里。所以，基本上你會發現作者的類是這樣的：
這樣，對于不同的屏幕尺寸就會保留各自的媒體查詢。 提示：你需要在你的CSS中使用反斜杠使用 @ ，如下所示：
.c-image-list\@small-screen { /* styles here */}我沒有太多的示例創建這些類型的組件，但是你必須這樣子做，這感覺將會是一種十分有好的開發商方式。 下面接管你代碼的人應該也能夠很容易地理解你的意圖。 我不主張像 small-screen 和 large-screen 的命名 - 這里純粹是為了可讀性。
BEM絕對是我在創建一個具有模塊化，組件驅動方式的應用中的一個救星。現在我已經使用了近三年，上述問題是也是我遇到的為數不多的絆腳石。 我希望這篇文章對你的學習有所幫助，另外如果BEM不過時，我強烈建議你這樣做。
本文根據 @David Berner 的《 Battling BEM (Extended Edition): 10 Common Problems And How To Avoid Them 》所譯，整個譯文帶有我們自己的理解與思想，如果譯得不好或有不對之處還請同行朋友指點。如需轉載此譯文，需注明英文出處: https://www.smashingmagazine.com/2016/06/battling-bem-extended-edition-common-problems-and-how-to-avoid-them/ 。
在校學生，本科計算機專業。一個積極進取、愛笑的女生，熱愛前端，喜歡與人交流分享。想要通過自己的努力做到心中的那個自己。微博：@靜-如秋葉
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com
Copyright ? 2019-2025 m.alabama37th.com 版權所有
違法及侵權請聯系：TEL:177 7030 7066 E-MAIL:11247931@qq.com 本站由北京市萬商天勤律師事務所王興未律師提供法律服務
