bem开发模式
At the start of the year, I put together an article on BEM and SMACSS that focused on the confusion of choosing a CSS methodology. I contacted a range of different developers and got their words of advice, their success stories and their horror stories in the hope that others could learn from their experiences with these popular CSS methodologies.
在今年年初，我整理了一篇有关BEM和SMACSS的文章 ，重点关注选择CSS方法论的困惑。 我联系了许多不同的开发人员，并得到了他们的建议，成功的故事和恐怖的故事，希望其他人可以从他们使用这些流行CSS方法学到的经验教训。
The article was quite well received, but there was a recurring question I’d seen over and over again with BEM that the article didn’t cover clearly: How do you deal with BEM at scale?
这篇文章收到了很多好评，但是我在BEM上反复出现了一个反复出现的问题，即该文章没有明确涵盖： 您如何大规模地处理BEM？
It was all well and good to say BEM is beneficial (it is!), but often the guides on the web for BEM stick to the basics. They tell you to arrange things into block__element--modifier but there isn’t a lot of guidance on what to do when things get messy. Is block__element__subelement--modifier okay? Is there a best practice for arranging your CSS files? Should you use @extend to inherit parent class values or should you list those in your HTML?
可以说BEM是有益的(这是好事！)，但这很好，但是BEM的网上指南通常都遵循基本原则。 他们告诉您将事情安排在block__element--modifier但是当事情变得混乱时，没有很多指导。 block__element__subelement--modifier可以吗？ 是否有安排CSS文件的最佳实践？ 应该使用@extend继承父类值还是应在HTML中列出它们？
In this article, I wanted to get the thoughts of developers who’ve had experience working with BEM at scale already — what do they do? What lessons have they learned in the process that would be good for us to know beforehand?
在本文中，我想了解已经有大规模使用BEM经验的开发人员的想法-他们做什么？ 他们在此过程中学到了什么教训，这些教训对我们事先是有好处的？
One thing you’ll find is there are some differing opinions — but that’s okay. I’ve tried to include as many of the responses as possible, even if they include contradictory views, so that readers can make up their own minds.
您会发现一件事是有一些不同的意见-没关系。 我试图包括尽可能多的答复，即使它们包含矛盾的观点，以便读者下定决心。
一些背景 (Some Background)
BEM originated at Yandex, a Russian search engine. It has since evolved into two different streams of use — it can be either the whole BEM stack that Yandex created (CSS, JS, HTML templating and development tools) or it can be solely the CSS methodology behind it.
BEM起源于俄罗斯搜索引擎Yandex 。 从那以后，它演变成两种不同的使用方式-它可以是Yandex创建的整个BEM堆栈(CSS，JS，HTML模板和开发工具)，也可以只是其背后CSS方法。
The latter approach has evolved from the Yandex concept via ideas by Nicolas Gallagher, Harry Roberts, and many others. The team at CSS-Tricks did a great write up on the CSS BEM methodology recently too — worth checking out!
后一种方法是从Yandex概念演变到Nicolas Gallagher ， Harry Roberts和许多其他人的想法的 。 CSS-Tricks团队最近在CSS BEM方法论方面也做了出色的写作 -值得一试！
This article will cover a bit of both worlds as I thought it was best to include both perspectives. However, quite a large proportion of the respondents focus solely on the CSS methodology rather than the Yandex BEM stack.
由于我认为最好同时包含这两种观点，因此本文将涉及两个领域。 但是，相当大比例的受访者仅关注CSS方法，而不关注Yandex BEM堆栈。
才华横溢的开发人员 (The talented developers that let me into their minds)
I’ll start by introducing the developers who were kind enough to let me into their minds to get some tips and advice on using BEM at scale. I was lucky enough to find BEM enthusiasts from all over the world — I’ve got responses from the Netherlands, Sweden, UK, Crimea, and Estonia! A very big thank you to all of them for taking the time to answer my questions.
我将首先介绍足够善良的开发人员，让我进入他们的头脑，以获取一些有关大规模使用BEM的技巧和建议。 我很幸运地找到了来自世界各地的BEM爱好者-我得到了荷兰，瑞典，英国，克里米亚和爱沙尼亚的回应！ 非常感谢他们花时间回答我的问题。
Bob Donderwinkel, a front-end developer from Rotterdam – Website, Twitter
Hamish Taplin, a front-end developer working for Bluegg in Cardiff – Website, Twitter
Harry Roberts, a Consultant Front-end Architect, designer, developer and absolute BEM guru from the UK – Website, Twitter
哈里·罗伯茨 ( Harry Roberts) ，顾问前端架构师，设计师，开发商和来自英国的绝对BEM专家– 网站 ， Twitter
Vladimir Grinenko, the head of the BEM development group at Yandex – Website, Twitter
Vladimir Starkov, a front-end developer from Sweden who is one of the founders of getbem.com and previously also worked at Yandex – Website, Twitter
Vladimir Starkov ，来自瑞典的前端开发人员，是getbem.com的创始人之一，之前还曾在Yandex – 网站 ( Twitter)工作
Let’s get started looking at the advice from these developers!
让我们开始看看这些开发人员的建议！
嵌套时要小心 (Be careful with nesting)
Nesting is one of the biggest dangers I’ve seen with development teams using BEM. It is very easy to go overboard and make things much more complicated than necessary. I wanted to know, is naming a class .block__element__subelement--modifier okay? Or should you stick to no more than the two levels of parent and child in .block__element--modifier? Different developers have different levels of nesting that they’re okay with, so I’ll cover both viewpoints.
嵌套是我在使用BEM的开发团队中看到的最大危险之一。 太容易了，使事情变得不必要的复杂。 我想知道，是否为类.block__element__subelement--modifier命名？ 还是应该只在.block__element--modifier中.block__element--modifier父级和子级两个级别？ 不同的开发人员可以使用不同级别的嵌套，因此我将介绍两种观点。
没有嵌套超过两个级别 (No nesting beyond two levels)
This was my personal preference and appears to be the most commonly followed practice by the developers I interviewed.
这是我的个人喜好，并且似乎是我采访的开发人员最常遵循的做法。
Vladimir Starkov pointed out his concern for block__element__subelement--modifier nested classes, saying “it is the wrong way, you should always have an option to use one element without another.”
弗拉基米尔·斯塔科夫(Vladimir Starkov)指出了他对block__element__subelement--modifier嵌套类的关注，他说：“这是错误的方式，您应该始终可以选择使用一个元素而没有另一个元素。”
Bob Donderwinkel also gradually moved to this approach: “I used the block__element__subelement—modifier notation at first, but that is not optimal and a little superfluous. So I try to sticking with block__element—modifier now, and that’s also easier on the eye ;)”
鲍勃·唐德温克尔(Bob Donderwinkel)也逐渐采用了这种方法：“起初，我使用了block__element__subelement—modifier表示法，但这并不是最优的，有点多余。 因此，我现在尝试使用block__element—modifier ，而且在眼睛上也更容易;)”
“It doesn’t really serve a purpose and over complicates your CSS. And also perhaps the extra file size hit which some styles of Sass/LESS nesting can produce. The resulting CSS can get pretty extensive.”
“它实际上并没有达到目的，并且会使CSS变得过于复杂。 还有一些样式的Sass / LESS嵌套可能产生的额外文件大小损失。 由此产生CSS可以变得非常广泛。”
Vladimir Grinenko from Yandex agrees with avoiding nesting too, suggesting making the element name longer if needed, rather than adding more levels of nesting:
Yandex的Vladimir Grinenko也同意避免嵌套，建议在需要时使元素名称更长，而不是增加更多级别的嵌套：
“There’s no need to resemble nesting in entity names. DOM structure is enough for that. Nesting may change in the future and the best way to avoid renaming things while refactoring is to name them properly from the very beginning.
“没有必要像实体名称中的嵌套一样。 DOM结构就足够了。 嵌套可能会在将来发生变化，并且在重构时避免重命名的最佳方法是从一开始就正确命名它们。
In case you really need to resemble nesting in the name, consider doing it with just longer name of an element: block__element-subelement”
如果确实需要在名称中使用嵌套，可以考虑使用元素的更长名称来完成： block__element-subelement ”
Harry Roberts explained the idea of this to me in quite possibly the best way I’ve ever seen, so I’ve included it below almost completely unedited:
哈里·罗伯茨(Harry Roberts)可能以我见过的最好的方式向我解释了这个想法，因此我将其几乎完全未经编辑地包括在下面：
“One important thing to know about BEM—and something that I feel causes problems for a lot of developers—is that you do not step through each layer of the DOM. To use a metaphor, the following is incorrect:
“要了解BEM的重要一件事-我认为这会给很多开发人员带来麻烦-是您没有逐步遍历DOM的每一层。 要使用隐喻，以下内容是不正确的：
.person {}
.person__head {}
.person__head__face {}
.person__head__face__eye {}
.person__head__face__eye__pupil {}“This is terribly verbose and also forces a DOM structure upon us; it is very inflexible. Instead we should write:
“这非常冗长，也迫使我们使用DOM结构； 这是非常不灵活的。 相反，我们应该这样写：
.person {}
.person__head {}
.person__face {}
.person__eye {}
.person__pupil {}“This is much more terse; it doesn’t force any DOM structure upon us, and we can visually indent rulesets to show us an implied DOM structure.
“这要简洁得多； 它不会对我们施加任何DOM结构，并且我们可以在视觉上缩进规则集以向我们展示隐含的DOM结构。
“If you do need to nest one Block inside another then just use traditional nesting. To continue our metaphor:
“如果确实需要将一个块嵌套在另一个块中，则只需使用传统的嵌套即可。 继续我们的隐喻：
.person {
clothing: pyjamas;
.outside & {
clothing: covered;
}
}“This time we want to style Person because it’s Outside—we don’t need to invoke or use anything BEMmy here. (N.B. we are using Sass’ parent selector nesting for better encapsulation here.) Alternatively, though, we could use something like this:
“这次，我们要为Person设置样式，因为它在外面，我们不需要在这里调用或使用任何BEMmy。 (注意，我们在这里使用Sass的父选择器嵌套来更好地封装。)但是，我们也可以使用如下所示的方法：
.person {
clothing: pyjamas;
}
.person--covered {
clothing: covered;
}“We can use BEM here in order to create a variation of a person who can be covered regardless of where they are.”
“我们可以在这里使用BEM，以创建一个无论身在何处都能被覆盖的人的变体。”
Hamish Taplin doesn’t really follow a strict rule with this but aims to keep things to element and subelement where possible:
Hamish Taplin对此并没有真正遵循严格的规则，但其目的是在可能的情况下将元素保持在元素和子元素中：
“I try to keep things as simple as possible. I have no real preference as it happens so rarely but I generally find that just separating the element/subelement into its own element is enough. An example of this would be whenever you have some of repeating elements inside an element that has its own components (such as header/footer). For example, you could do this:
“我试图使事情尽可能简单。 我没有真正的偏爱，因为这种情况很少发生，但是我通常发现仅将元素/ subelement分离为其自己的元素就足够了。 这样的一个例子是，当您在具有自己的组件(例如页眉/页脚)的元素中包含一些重复元素时。 例如，您可以这样做：
.list__header
.list__items
.list__item
.list__item__header
.list__item__body
.list__item
.list__item__header
.list__item__body
.list__item
.list__item__header
.list__item__body
.list__footer“However, I prefer to just separate those elements:
“但是，我更喜欢将这些元素分开：
.list__header
.list__items
.list-item
.list-item__header
.list-item__body
.list-item
.list-item__header
.list-item__body
.list-item
.list-item__header
.list-item__body
.list__footer“So now we have a ‘list’ element and a ‘list-item’ element that isn’t tied to the ‘list’. I can’t really comment on the pros and cons of this approach because I haven’t given it a great deal of thought, but it’s worked well for me so far!”
“因此，现在我们有了一个“列表”元素和一个与“列表”无关的“列表项”元素。 我无法真正评论这种方法的优缺点，因为我没有考虑太多，但是到目前为止对我来说效果很好！”
但是，并非所有人都同意严格的方法 (However, not everyone agrees with the strict approach)
Serge Herkül had a different approach to the nesting restrictions which warrants a mention as I know of other teams that do the same. His team does go beyond two levels deep. He said:
SergeHerkül对嵌套限制采用了不同的方法，正如我所知道的其他这样做的团队一样，值得一提。 他的团队确实超越了两个层次。 他说：
“We use block__element__subelement--modifier when needed. Try not to get too strict with how the ‘original’ BEM sees things and bend things to your own needs.”
“我们在需要时使用block__element__subelement--modifier 。 尽量不要对“原始” BEM如何看待事物以及使事物满足自己的需求变得过于严格。”
在开始块范围时要谨慎 (Be cautious with where you start your block scope)
A common mistake Harry Roberts has seen is developers starting their Block scope too high up. He gives the following example of incorrect CSS:
哈里·罗伯茨(Harry Roberts )看到的一个常见错误是，开发人员开始将Block范围设置得过高。 他给出了以下错误CSS示例：
.room {}
.room__floor {}
.room__desk {}
.room__laptop {}Harry explains, “Here we can see we’re scoping the laptop to the desk to the room. The issue here is that that laptop could be in my bag in the trunk of a car; that desk could be moved into the corridor; the laptop could be placed straight on the floor of the room.”
哈里解释说：“在这里，我们可以看到我们正在将笔记本电脑的范围限定在房间的桌子上。 这里的问题是笔记本电脑可能放在我的后备箱中，放在汽车后备箱中。 那张桌子可以移到走廊上； 笔记本电脑可以直接放在房间的地板上。”
Instead, the focus should be on separating out the DOM elements that can live independently of one another. Start your Block scope from “the smallest, most self-sufficient bit”. As an example, Harry provided the following solution to the incorrect CSS above:
相反，重点应该放在分离可以彼此独立存在的DOM元素上。 从“最小，最自给自足的位”开始您的块作用域。 例如，Harry为上面的错误CSS提供了以下解决方案：
.room {}
.room__floor {}
.desk {}
.laptop {}Harry points out, “The laptop now has no dependency on anything, nor does the desk. This is how it should be.”
哈里指出：“笔记本电脑现在不再依赖任何东西，桌子也不再依赖。 这应该是这样。”
将CSS分成易于理解的文件 (Separate your CSS in easy to understand files)
Serge Herkül had a focus on keeping things modular and in separate files to assist in scaling up BEM. He said, “Our entire SPA is made out of modules. Roughly speaking we have a SCSS file for each module or module group (if it’s made of smaller modules).” He recommends the modular approach for both CSS and JS: “Try combining your JS and CSS modules so they would share the same name (profile_picture.js and profile_picture.scss).”
SergeHerkül专注于保持模块模块化并放在单独的文件中，以帮助扩展BEM。 他说：“我们的整个SPA都是由模块组成的。 大致来说，我们为每个模块或模块组都有一个SCSS文件(如果它由较小的模块组成)。” 他建议CSS和JS都采用模块化方法：“尝试结合使用JS和CSS模块，以便它们共享相同的名称( profile_picture.js和profile_picture.scss )。”
Harry Roberts says “each file should be as small as possible but as large as necessary”.
哈里·罗伯茨 ( Harry Roberts)说：“每个文件应尽可能小，但应尽可能大”。
Vladimir Starkov had separated files per block, modifiers and elements when previously working at Yandex but has found it is easier to focus on separating by block:
弗拉基米尔·斯塔科夫(Vladimir Starkov)以前在Yandex工作时曾按块，修饰符和元素分隔文件，但发现集中于按块分隔更容易：
“In Yandex we usually separate styles per block, its modifiers, its elements and for their modifiers. But in reality it is very hard to support all these separations. That’s why in pet projects I and ex-Yandexers support a one-file-per-block structure, which is flexible and good enough to support and maintain. Best tip is to extract blocks into different files, one block per file. There is a brilliant article in English by Vladimir (@mistakster) at frontendbabel.info/articles/bem-with-css-preprocessors/ explaining how to maintain your selector’s structure inside block files.”
“在Yandex中，我们通常将每个块的样式，其修改器，其元素及其修改器分开。 但是实际上很难支持所有这些分离。 这就是为什么在我的宠物项目中，我和以前的Yandexer支持每个块一个文件的结构，该结构灵活且足以支持和维护。 最好的技巧是将块提取到不同的文件中，每个文件一个块。 Vladimir( @mistakster )在frontendbabel.info/articles/bem-with-css-preprocessors/上有一篇精彩的英文文章，解释了如何在块文件中维护选择器的结构。”
Bob Donderwinkel considers his approach on a project by project basis depending on how complex things get, but also adapts some SMACSS concepts:
鲍勃·唐德温克尔(Bob Donderwinkel)根据事情的复杂程度来考虑每个项目的方法，但也适应了SMACSS的一些概念：
“It depends on the project. I started out by using different files for each Block, and then perhaps files for each Element and Modifier if those got extensive. But nowadays I also use a SMACSS baseline for files often, and fill those with BEM CSS.”
“这取决于项目。 首先，我为每个块使用了不同的文件，然后对每个元素和修饰符使用了不同的文件(如果扩展的话)。 但是如今，我也经常对文件使用SMACSS基线，并使用BEM CSS填充这些文件。”
Vladimir Grinenko says Yandex’s focus is on separating by block, with elements and modifiers separated when necessary:
弗拉基米尔·格林尼科 ( Vladimir Grinenko)说，Yandex的重点是按块分隔，必要时将元素和修饰符分隔开：
“We store each block in a separate folder. For elements and modifiers additional folders are optional (having them in different files gives us possibility to build a project with just needed parts). e.g.
“我们将每个块存储在单独的文件夹中。 对于元素和修饰符，其他文件夹是可选的(将它们放在不同的文件中使我们可以构建仅包含所需部分的项目)。 例如
blocks/
button/
button.css
header/
__logo/
header__logo.css
header.css
footer/
footer.css“Then build tools look at what BEM entities (blocks, elements and modifiers) are there and concatenate needed files in their proper order.”
“然后，构建工具将查看其中存在哪些BEM实体(块，元素和修饰符)，并以适当的顺序连接所需的文件。”
Hamish Taplin has found his style for structuring CSS files has changed over time and provided an insight into where he’s moving towards and why:
Hamish Taplin发现他用于构造CSS文件的样式已随着时间而改变，并提供了关于他前进的方向以及原因的见解：
“Previously, I was building my Sass in a structure inspired by SMACSS:
“以前，我是在受SMACSS启发的结构中构建Sass的：
- base (base-styling for typography, forms, tables, grid, etc) 基本(印刷，表格，表格，表格等的基本样式)
- helpers (Sass functions and mixins) 助手(Sass函数和mixins)
- modules (My BEM modules) 模块(我的BEM模块)
- vendor (3rd party stuff) 供应商(第3方材料)
“The contents of everything other than ‘modules’ would remain pretty much the same from project-to-project with only some ‘base’ styling being done on a per-project basis. This would include the basic typographical styling (headings, body copy, etc) for that project and things like tables and forms will be styled.
“除了'模块'之外，所有内容的内容在项目之间将保持几乎相同，每个项目仅完成某些'基础'样式。 这将包括该项目的基本印刷样式(标题，正文等)，并且将对表格和表格等样式进行样式化。
“Everything else goes in ‘modules’ with one file per module. This might look something like:
“其他所有内容都在“模块”中，每个模块只有一个文件。 这可能看起来像：
- modules
-- article
-- avatar
-- dropdown
-- feature
-- list
-- media
-- nav
-- panel
-- section“However, dumping everything in a ‘module’ wasn’t really working for me as not every bit of styling can be abstracted into a re-usable module. Obviously, writing re-usable code should be done as much as possible but the realities of deadlines and budgets dictate that sometimes you just need to get something styled and move on. I had it in the back of my mind to look for a better way and had experimented with dropping the BEM syntax for styling that wasn’t intended to be re-usable. I tried this out on a couple of projects and wasn’t really that happy with it.”
“但是，将所有内容都转储到'模块'中并不是一件真正的事情，因为并非所有样式都可以抽象为可重用的模块。 显然，编写尽可能多的可重用代码应该做得很好，但是截止日期和预算的现实状况决定了有时候您只需要获取样式并继续前进即可。 我曾想过要找到一种更好的方法，并尝试删除BEM语法来进行样式设计，而这些样式本来是不可重用的。 我在几个项目上进行了尝试，对此并不满意。”
Hamish was then influenced by an article by Harry Roberts on namespacing, which Harry himself actually explains a bit further down in this article (it’s wonderful when responses link together so nicely!):
哈米什(Hamish)随后受到哈里·罗伯茨(Harry Roberts)关于命名空间的一篇文章的影响，哈里本人实际上在这篇文章中对此作了进一步解释(当反馈如此完美地结合在一起时，真是太好了！)：
“A few weeks ago, Harry Roberts published an article on using namespacing to get better control over large scale codebases. Although I haven’t completely adopted his approach, he makes some really good points about the types of abstractions he uses. This made a few things ‘click’ for me and I came up with a new approach to structuring my Sass that I’ve been trialing recently:
“几周前，哈里·罗伯茨(Harry Roberts)发表了一篇有关使用命名空间的文章，以更好地控制大规模代码库。 尽管我还没有完全采用他的方法，但是他对他使用的抽象类型提出了一些非常好的观点。 这让我感到有些“点击”，我想出了一种新的方法来构造我最近尝试的Sass：
- base 基础
- components 组件
- helpers 帮手
- objects 对象
- vendor 供应商
“The only real difference so far is that I’ve split what I previously called ‘modules’ into two folders called ‘objects’ and ‘components’. Basically, ‘objects’ are pure abstractions such as the ‘media’ object and my own grid system whereas ‘components’ are self-contained implementations of styling such as ‘dropdown’ or ‘signup form’. Those components might even be based on an ‘object’ but will more likely be project-specific whereas the ‘objects’ are much more re-usable between projects.”
“到目前为止，唯一真正的区别是，我将以前称为'模块'的内容分成两个文件夹，分别称为'对象'和'组件'。 基本上，“对象”是纯抽象概念，例如“媒体”对象和我自己的网格系统，而“组件”是样式的独立实现，例如“下拉”或“注册形式”。 这些组件甚至可能基于“对象”，但更有可能是特定于项目的，而“对象”在项目之间的可重用性更高。”
ITCSS和源排序 (ITCSS and source ordering)
Harry Roberts has his own methodology for structuring BEM CSS called ITCSS, which keeps things easier to manage and scale. Harry explains it as a methodology that allows you to “break your projects up based around Specificity, Explicitness, and Reach”. He focuses on a specific CSS source order, arranging styles into layers of different levels of specificity. More specific stylings have layers placed near the end of your CSS and globally shared variables, mixins and styles are in layers at the start.
哈里·罗伯茨(Harry Roberts)有自己的方法来构建BEM CSS(称为ITCSS)，从而使事情更易于管理和扩展。 哈里(Harry)将其解释为一种方法，可以让您“基于专长，明确性和影响力来分解项目”。 他专注于特定CSS源代码顺序，将样式分为不同级别的特异性。 更具体的样式在CSS的末尾放置了图层，并且全局共享变量，mixin和样式在开始时位于图层中。
If you’d like more info on the ITCSS framework, Harry’s presentation “Managing CSS Projects with ITCSS” is a great resource (if you’d prefer just slides rather than a YouTube link, they can be found here). ITCSS is a really well thought out framework for keeping CSS manageable at scale and is definitely worth a look.
如果您想要有关ITCSS框架的更多信息，Harry的演讲“使用ITCSS管理CSS项目”是一个很好的资源(如果您只喜欢幻灯片而不是YouTube链接， 可以在这里找到 )。 ITCSS是一个经过深思熟虑的框架，可以使CSS保持大规模可管理性，并且绝对值得一看。
命名空间 (Namespaces)
Harry Roberts recommends augmenting BEM with namespaces. This involves creating a set of namespaces for things like theme classes (in other words, this class is restyling child elements to match a certain theme), state classes (e.g. is-active) and many more. I’ve seen various developers using namespacing recently in various ways, some using ideas from SMACSS (such as state classes of is-active and layout classes for overall layout containers).
哈里·罗伯茨(Harry Roberts)建议使用名称空间扩充BEM。 这涉及为主题类(换句话说，该类正在重新设置子元素的样式以匹配某个主题)，状态类(例如is-active )等创建一组名称空间。 我看到最近有各种各样的开发人员以各种方式使用命名空间，其中一些使用了SMACSS的想法(例如is-active状态类和整体布局容器的布局类)。
Harry explained the beneficial relationship between BEM and namespacing really well. He said, “I augment BEM with my own suite of namespaces. This adds a whole other layer to the meaningful naming that BEM gives us by signalling the role of a class in non-relative terms: where BEM tells us how classes are related to each other (e.g. .foo__bar must live inside of .foo), namespacing tells us what a class does in absolute terms (e.g. .t-* tells us this class is theme related).”
哈里很好地解释了BEM和命名空间之间的有益关系。 他说：“我用自己的命名空间套件增强了BEM。 BEM通过用非相对的术语表示类的作用，从而给BEM给我们的有意义的命名又增加了另一层：BEM告诉我们类之间如何相互关联(例如.foo__bar必须位于.foo )，名称.t-*告诉我们类绝对的作用(例如.t-*告诉我们该类与主题相关)。”
Harry’s post outlining the namespaces he uses (the one Hamish mentioned earlier) provides more details and can be found at More Transparent UI Code with Namespaces.
哈利(Harry)概述了他使用的命名空间(前面提到的Hamish命名空间)提供了更多详细信息，可以在使用名称空间的更透明的UI代码中找到。
不要害怕班长名 (Don’t be afraid of long class names)
Serge Herkül also suggests a focus on self documenting class names. Don’t be afraid of long class names! His advice – “Use long, descriptive class names over short names that don’t document themselves.”
SergeHerkül还建议将重点放在自我记录类名上。 不要害怕长类的名字！ 他的建议–“在不记录自己的短名称上使用长的，描述性的类名称。”
避免Sass'@extend (Avoid Sass’ @extend)
I provided the two different formats I’ve seen people use with BEM to the developers to get their thoughts on which they use and why. The first was the style similar to object oriented CSS:
我向开发人员提供了我已经看到人们与BEM一起使用的两种不同格式，以了解他们使用的方式以及原因。 首先是类似于面向对象CSS的样式：
<div class="block">
<div class="block__element"></div>
<div class="block__element"></div>
<div class="block__element block__element--modifier"></div>
</div>The second was the style that uses Sass to handle inheritance:
第二种是使用Sass处理继承的样式：
<div class="block">
<div class="block__element"></div>
<div class="block__element"></div>
<div class="block__element--modifier"></div>
</div>I had a unanimous agreement from all the developers on this one. Don’t use @extend where possible — go with the first option!
我得到了所有开发人员的一致同意。 不要在可能的情况下使用@extend选择第一个！
Harry Roberts recommends avoiding @extend and instead keeping styles defined within classes in your markup (like the first markup example above). His thoughts on this were:
哈里·罗伯茨(Harry Roberts)建议避免使用@extend ，而应在标记的类中保留定义的样式(如上面的第一个标记示例)。 他对此的想法是：
“You can create a greater number of combinations in the view by not ‘tying’ classes together in Sass. The HTML has a much better paper trail in that you can see every class acting on a piece of the DOM. Your CSS stays much slimmer in that you don’t have to create new placeholder classes (or the manifest classes that combine them) every time you want to create a new piece of UI.”
“通过不在Sass中将类“捆绑”在一起，您可以在视图中创建更多组合。 HTML具有更好的书面记录，因为您可以看到每个类都在DOM上起作用。 您CSS保持纤细，因为您不必每次想创建新的UI时都创建新的占位符类(或将它们组合在一起的清单类)。”
Vladimir Starkov agreed with avoiding the second option as it leads to much bigger CSS files. He prefers “declarative in HTML” with “clean and minimum sized CSS”. He suggested the use of automatically generated systems:
弗拉基米尔·斯塔科夫(Vladimir Starkov)同意避免使用第二种选择，因为这会导致更大CSS文件。 他更喜欢“ HTML声明式”和“干净且最小尺寸CSS”。 他建议使用自动生成的系统：
“If you are confused with HTML classes that are a bit messy, then you can generate them automatically. You can try kizu/bemto on github for a jade templating system and azproduction/b_ on github for any nodejs-base templating systems to achieve that automation goal.”
“如果您对有点混乱HTML类感到困惑，则可以自动生成它们。 您可以在github上的kizu / bemto上尝试一个玉器模板系统， 在github上的azproduction / b_来尝试任何基于nodejs的模板系统来实现该自动化目标。”
Bob Donderwinkel also agreed with the object-oriented option:
Bob Donderwinkel也同意面向对象的选择：
“I personally use the object-oriented approach because it is a little more tech-agnostic. Concerning the Sass approach I actually tried to make things even more ‘organized’ by using multiple modifiers in a single BEM class name (https://gist.github.com/BobD/e51edd989e43aaf3d74d). But the CSS it produced was pretty awful.”
“我个人使用面向对象的方法，因为它与技术无关。 关于Sass方法，我实际上试图通过在单个BEM类名称( https://gist.github.com/BobD/e51edd989e43aaf3d74d )中使用多个修饰符来使事情更加“有条理”。 但是它产生CSS太糟糕了。”
If you needed any more encouragement to avoid Sass’s @extend, Hamish Taplin provided another good example of why it’s better to structure things into multiple classes:
如果您需要更多鼓励来避免Sass的@extend ，那么Hamish Taplin提供了另一个很好的示例，说明了为什么最好将事物构造成多个类：
“I very much encourage using the ‘multi-class’ approach in the first example over the ‘single-class’ in the second example. The biggest problem with the ‘single-class’ approach is related to nesting and makes it an anti-pattern, in my opinion. Consider the following example whereby we want to apply a small change to a .btn inside a .signup-form, making it full width. If we use the multi-class approach to modifiers we can do the following:
“与第二个示例中的“单个类”相比，我非常鼓励在第一个示例中使用“多类”方法。 我认为，“单类”方法的最大问题与嵌套有关，并使其成为反模式。 考虑下面的示例，在此示例中，我们希望对.btn内的.signup-form进行少量更改，使其.signup-form全角。 如果我们对修饰符使用多类方法，则可以执行以下操作：
.signup-form {
.btn {
width: 100%;
}
}“Here, any instance of the .btn will be styled accordingly in the relevant context. If we had adopted the single-class pattern and our .signup-form had a modified .btn--blue then our CSS fails and we have to add every type of .btn modifer to our .signup-form styling context. This would be a maintenance nightmare for obvious reasons!”
“在此，任何.btn实例.btn将在相关上下文中进行相应样式设置。 如果我们采用了单类模式，并且.signup-form具有修改后的.btn--blue那么CSS将会失败，我们必须将每种类型的.btn修饰符添加到我们的.signup-form样式上下文中。 出于明显的原因，这将是一场维护噩梦！”
整理您CSS！ (Lint your CSS!)
Harry Roberts also has a brilliant system for ensuring all CSS keeps to the right naming convention: he lints his CSS using scss-lint to ensure all team members stick to the convention correctly. As Harry put it, “It’s all well and good telling the team to use BEM, but it’s important to police it as well.”
哈里·罗伯茨(Harry Roberts)拥有一套出色的系统，可确保所有CSS都遵循正确的命名约定：他使用scss-lint插入CSS，以确保所有团队成员正确遵守约定。 正如哈里所说，“告诉团队使用BEM很好，但也必须对其进行监管也很重要。”
Harry even wrote a regex to use with scss-lint that works to detect his style of namespaced BEM classes. You can find that at the More Transparent UI Code with Namespaces article mentioned earlier.
Harry甚至编写了一个正则表达式以与scss-lint一起使用，该正则表达式用于检测他的命名空间BEM类的样式。 您可以在前面提到的“使用名称空间更透明的UI代码”文章中找到该代码 。
选择最适合您的工具和工作流程 (Choose the tools and workflow that work best for you)
Vladimir Grinenko from Yandex was keen to point out that BEM can be about more than just CSS classes. Yandex has a whole range of tools to compliment the BEM methodology and bring it into your JavaScript and templates too.
Yandex的Vladimir Grinenko敏锐地指出，BEM不仅仅是CSS类。 Yandex提供了各种各样的工具来完善BEM方法并将其引入您JavaScript和模板中。
“One of the most important things about the BEM methodology is that it’s not just about CSS names but it’s all about the same things as Web Components: each BEM block knows everything about itself (styles, JS, templates, images, tests, documentation, etc).
“关于BEM方法论的最重要的事情之一是，它不仅与CSS名称有关，而且与Web组件具有相同的含义：每个BEM块都了解有关其自身的所有信息(样式，JS，模板，图像，测试，文档，等等)。
“We use the object-oriented declarative approach everywhere: in CSS, JavaScript and templates.
“我们到处都使用面向对象的声明性方法：在CSS，JavaScript和模板中。
“Also, we have such powerful concepts like mixes — when there could be more then one BEM block on one DOM node: <div class="b1 b2 b3__elem1"></div>.”
“此外，我们还有混合之类的强大概念-当一个DOM节点上可能有一个以上的BEM块时： <div class="b1 b2 b3__elem1"></div>. ”
For details on the tools and the BEM stack from Yandex, see bem.info.
有关Yandex的工具和BEM堆栈的详细信息，请参见bem.info 。
As I mentioned above, many developers I know prefer to focus just on the CSS aspect of BEM. However, this doesn’t mean sacrificing the ability to have a fully featured workflow. The Yandex tools can be beneficial for some projects but there are alternatives for those who prefer to use different workflows too. Yandex even provides workshops to help developers use BEM with things like Gulp, Angular, and more.
如上所述，我认识的许多开发人员都更喜欢只关注BEMCSS方面。 但是，这并不意味着要牺牲具有完整功能的工作流程的能力。 Yandex工具对于某些项目可能是有益的，但是对于那些也喜欢使用不同工作流的人来说，还有其他选择。 Yandex甚至提供了研讨会来帮助开发人员将BEM与Gulp，Angular等一起使用。
Vladimir Starkov prefers to focus on the CSS methodology and recommends finding the workflow that works best for your team:
弗拉基米尔·斯塔科夫(Vladimir Starkov)倾向于专注于CSS方法，并建议找到最适合您的团队的工作流程：
“Basically BEM is only a CSS methodology, and all the stuff invented by Yandex is only their way to make code sharing between teams simpler.
“基本上，BEM只是一种CSS方法，Yandex发明的所有东西只是它们使团队之间的代码共享更简单的方式。
“From this point of view it’s good to understand that you don’t need to use full yandex-bem-stack with bemjson, bh, priv and bem-tools, because this way is very inflexible and hard to be implemented in other workflows.
“从这个角度来看，很高兴知道您不需要将完整的yandex-bem-stack与bemjson，bh，priv和bem-tools一起使用，因为这种方式非常不灵活，很难在其他工作流程中实现。
“To be honest it was a reason for us to create gulp-bem and getbem.com, we wanted to deliver BEM to people in the easiest way.”
“说实话，这是我们创建gulp-bem和getbem.com的原因 ，我们希望以最简单的方式向人们提供BEM。”
From what I gather from our devs, there are plenty of resources and tools to help you use BEM in the way that best suits your workflow. Use some aspects in your JavaScript and templating if that works in your team. Do some research and find the tools that suit your team and project. Combine them. Use some from Yandex and some from other developers. Try some of the cool stuff Harry Roberts has got going. Build your own! The power is yours. Just make sure you’ve got a solid workflow in place.
从我从开发人员那里收集的信息来看，有很多资源和工具可以帮助您以最适合您的工作流程的方式使用BEM。 在您JavaScript中使用一些方面，并确定是否可以在您的团队中使用。 做一些研究，找到适合您的团队和项目的工具。 合并它们。 使用Yandex和其他开发人员的软件。 尝试哈里·罗伯茨(Harry Roberts)的一些很棒的东西。 建立你自己的！ 力量是你的。 只要确保您有一个可靠的工作流程即可。
文献资料 (Documentation)
One aspect of Vladimir Grinenko’s advice earlier stood out to me — documentation. BEM provides a great base of structured components (your Blocks) to document and keep consistent throughout your project. If you can keep your naming and structure throughout all levels of your site (CSS, JS, HTML templates and documentation) organised by Block components, your project becomes easier to follow and expand. Combine that with the brilliant concepts in Harry Robert’s ITCSS methodology and a well documented and structured site should be just that little bit easier.
弗拉基米尔·格林宁科(Vladimir Grinenko)的建议的一个方面对我来说比较突出- 文档 。 BEM提供了强大的结构化组件(您的块)基础，可以记录整个项目并保持一致。 如果您可以在整个网站的各个级别(CSS，JS，HTML模板和文档)中使用Block组件来组织命名和结构，那么您的项目将变得易于遵循和扩展。 将其与哈里·罗伯特(Harry Robert)的ITCSS方法论中的精妙概念相结合，并有一个记录良好且结构化的网站应该会稍微容易一些。
避免过度自动化 (Avoid over-automation)
I thought this piece of advice from Bob Donderwinkel was quite valuable:
我认为Bob Donderwinkel的这条建议非常有价值：
“I guess my main word of advice would be to keep your BEM CSS portable to other projects if needed. This means not over-automating things so they are only useful in a single project environment. That is not to say you will eventually re-use that specific piece of CSS, but at the very least it will result in a clean CSS approach.”
“我想我的主要建议是，如果需要，将BEM CSS移植到其他项目中。 这意味着不会过度自动化，因此它们仅在单个项目环境中有用。 这并不是说您最终将重用该特定CSS，但至少会得到一种干净CSS方法。”
仍然没有在您的团队中尝试使用BEM？ (Still haven’t tried using BEM in your team?)
For those who haven’t taken the leap into giving BEM a go just yet, I thought I’d finish up the article with some words from Serge Herkül on his positive experience with BEM and Teamweek:
对于那些还没有尝试BEM的人，我想以SergeHerkül在BEM和Teamweek方面的积极经验来结束我的文章：
“We originally did not have any specific CSS structure and stuff just started to slip out of hand. There was a lot of Sass nesting going on, resulting in long CSS rules. Some styles were affecting other elements, that they were not supposed to, etc.
“我们最初没有任何特定CSS结构，并且东西开始失控。 大量的Sass嵌套正在进行，导致冗长CSS规则。 一些样式正在影响其他元素，这些元素本不该如此。
“Moving to BEM was a pretty straightforward process, a lot of manual labor but not too hard. In the end I cannot think of a better way, all of the problems we had before are gone.”
“迁移到BEM是一个非常简单的过程，需要大量的体力劳动，但并不太难。 最后，我无法想到更好的方法，我们之前遇到的所有问题都消失了。”
结论 (Conclusion)
I hope this series of interviews has provided a good set of tips and ideas for developers looking to implement BEM on large scale projects (or even small projects which always have the tendency to grow exponentially in ways you least expect). If you were previously unsure about using BEM on your next project, maybe this will give you a little bit more of a push to give it a go — the benefits are worth it!
我希望这一系列采访为希望在大型项目(甚至总是有以您最不期望的方式呈指数增长趋势的小型项目)中实施BEM的开发人员提供了一系列的技巧和想法。 如果您以前不确定在下一个项目中使用BEM，也许这会给您带来更多推动力-好处值得！
Have you got any tips or ideas on using BEM at scale that weren’t covered? Feel free to include your thoughts in the comments below.
您是否有未涵盖的大规模使用BEM的技巧或想法？ 随时在下面的评论中包含您的想法。
翻译自: https://www.sitepoint.com/working-bem-scale-advice-top-developers/
bem开发模式
1010
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
