bem开发模式
CSS methodologies can be mind bogglingly confusing and tough to decide upon. Let’s consider two of the most well known options: BEM and SMACSS.
CSS方法可能令人困惑，难以决定。 让我们考虑两个最著名的选项： BEM和SMACSS 。
Should you choose one of these for your next project? What are they best suited for? What might go wrong? If you’re already working with one – are you using it as intended? To the fullest potential? How do you know if you’re doing it right? I thought I’d be nice to ask people who’ve already been through those questions in their own projects and learn from their experiences.
您是否应该为下一个项目选择其中之一？ 他们最适合什么？ 可能出什么问题了？ 如果您已经在使用它-是否按预期使用它？ 发挥最大潜力？ 您怎么知道自己做得对吗？ 我想问问那些已经在自己的项目中经历过这些问题并从他们的经验中学习的人，我会很高兴。
I asked developers who’ve worked with BEM and/or SMACSS for their success stories, horror stories, advice, and words of caution. I gave some developers a whole list of questions and others just free-formed their thoughts to me. I’ve compiled the results into what I hope will be valuable reading for those considering optimizing their CSS.
我询问了与BEM和/或SMACSS一起工作过的开发人员，了解他们的成功故事，恐怖故事，建议和警告语。 我给了一些开发人员完整的问题清单，而其他人则只是自由地对我提出了自己的想法。 我将结果整理成希望对那些考虑优化CSS的人有价值的阅读内容。
For those new to BEM and SMACSS, I’ll start by giving a very high-level overview of what BEM and SMACSS are.
对于BEM和SMACSS的新手，我将首先简要介绍BEM和SMACSS是什么。
BEM stands for Block Element Modifier and originated at Yandex. It provides a rather strict way to arrange your CSS classes into independent modules. There are a few variations on the idea but the most common one looks like this:
BEM代表“ 块元素修改器” ，起源于Yandex。 它提供了一种相当严格的方式来将CSS类安排到独立的模块中。 这个想法有几种变体，但最常见的是这样的：
.block {} .block__element {} .block--modifier {} .block__element--modifier {}A Block represents an object in your website. For example:
块代表您网站中的一个对象。 例如：
a person 一个人 a login form 登录表单 a menu 一份菜单 a search form 搜索表格An Element is a component within the block that performs a particular function. It should only make sense in the context of its block. For example:
元素是块中执行特定功能的组件。 它仅在其块的上下文中才有意义。 例如：
a hand 一只手 a login button 登录按钮 a menu item 菜单项 a search input field 搜索输入字段A Modifier is how we represent the variations of a block. For example:
修饰符是我们如何表示块的变体。 例如：
a tall/short person 高个子/矮个子的人 a condensed login form (e.g. we’re hiding the labels in one version) 简明的登录表单(例如，我们将标签隐藏在一个版本中) a menu modified to look differently for a footer or sitemap 修改菜单以使页脚或站点地图看起来有所不同 a search input field with a particular button style 具有特定按钮样式的搜索输入字段In the example of our menu, the class names could look like this:
在我们的菜单示例中，类名称可能如下所示：
.menu {} .menu__item {} .menu__item--featured {} .menu--footer {}There are other architectural principles and tools for BEM on the bem.info website, however, when developers discuss BEM, they’re often focused mainly on the naming convention above and that is true of the majority of the discussion below.
bem.info网站上还有其他BEM的体系结构原则和工具，但是，当开发人员讨论BEM时，他们通常主要专注于上述命名约定，并且在下面的大多数讨论中也是如此。
SMACSS is a CSS framework by Jonathan Snook. On the SMACSS website, he says it is more like a “style guide” than a rigid CSS framework. It focuses on five categories for its rules:
SMACSS是Jonathan SnookCSS框架。 他在SMACSS网站上说，它更像是“样式指南”，而不是严格CSS框架。 它的规则集中在五个类别上：
Base is used for defaults like html, body, a, a:hover. This includes your CSS resets and would often be in its own base CSS file or at the start of your main CSS.
Base用于默认值，例如html ， body ， a ， a:hover 。 这包括您CSS重置，并且通常位于其自己的基本CSS文件中或主CSS的开头。
Layout divides a page into sections with elements like header, footer, and article. Often developers show layout elements by prefixing the class with l-.
布局将页面划分为包含页眉，页脚和文章等元素的区域。 开发人员通常通过在类前面加上l-显示布局元素。
Module is a reusable, modular element in the design. The SMACSS documentation sees modules as the majority of your elements and thus doesn’t require that you prefix them but you could do so if you choose.
模块是设计中可重用的模块化元素。 SMACSS文档将模块视为您的大多数元素，因此不需要您为它们加上前缀，但是如果您愿意，可以这样做。
State is used for the variations possible for each element (e.g. active, inactive, expanded, hidden). These are prefixed with is-, e.g. is-active, is-inactive, is-expanded, is-hidden or are via pseudo-classes such as :hover and :focus or media queries.
状态用于每个元素的可能变化(例如，活动，非活动，扩展，隐藏)。 它们以is-为前缀，例如is-active ， is-inactive ， is-expanded ， is-hidden或通过诸如:hover和:focus或媒体查询之类的伪类。
Theme is similar to state but defines how modules and layouts will look. It is more applicable for larger sites with shared elements that look different throughout. You would add theme variations on a per page or per section basis.
主题类似于状态，但定义了模块和布局的外观。 它更适用于具有共享元素的大型网站，这些元素在整个外观上都是不同的。 您将在每个页面或每个部分的基础上添加主题变体。
Child elements in SMACSS (like what an “element” is to a “block” in BEM) have the parent item prefixed with a dash. e.g. menu and menu-item.
SMACSS中的子元素(例如BEM中“元素”对“块”的含义)的父项带有短划线。 例如menu和menu-item 。
SMACSS states that it’s all up to developer preference and isn’t as prescriptive as BEM. SMACSS just provides basic guidelines. Use your own naming conventions for each of the categories and arrange them in your preferred way, as long as you document your approach so that other developers can follow along.
SMACSS指出，这完全取决于开发人员的喜好，并且不像BEM那样具有规定性。 SMACSS仅提供基本准则。 只要您记录了您的方法，以便其他开发人员可以遵循，就可以对每个类别使用自己的命名约定，并以首选的方式排列它们。
Hamish Taplin, a front-end developer from Cardiff, UK, believes BEM is suitable for projects big and small and it offers plenty of advantages:
来自英国卡迪夫的前端开发人员Hamish Taplin认为BEM适用于大小项目，并具有很多优势：
“BEM is touted as being for large projects but I don’t believe that at all. If you like writing code that is clean, maintainable, and not battling with specificity problems then BEM is for you. Some say that the HTML it produces is ugly or redundant but I think it’s beautiful. I can read some HTML and see exactly what is going on and how elements are related to each other. It’s great.”
“ BEM被吹捧为大型项目，但我一点也不相信。 如果您喜欢编写干净，可维护的代码，并且不担心特定性问题，那么BEM非常适合您。 有人说它产生HTML难看或多余，但我认为它很漂亮。 我可以阅读一些HTML，确切地了解正在发生的事情以及元素之间如何相互关联。 这很棒。”
Alec Raeside, a front-end developer from Sydney, Australia has found BEM to be a good way to avoid too much nesting of selectors:
来自澳大利亚悉尼的前端开发人员Alec Raeside发现BEM是避免选择器过多嵌套的好方法：
“BEM is a good way to build UI. The descriptive, sometimes long, class names are good for understanding straight away where this class/selector sits within your UI architecture. It also means you rarely need to nest selectors, a common downfall with Sass codebases. Usually when I’m nesting with BEM is when I want to target an element via HTML tag name, or to win a specificity battle when components styling overlaps.”
“ BEM是构建UI的好方法。 描述性的类名(有时很长)对于直接理解此类/选择器在您的UI体系结构中的位置非常有用。 这也意味着您几乎不需要嵌套选择器，这是Sass代码库的常见缺陷。 通常，当我要与BEM嵌套时，是想通过HTML标签名称来定位元素，或者当组件样式重叠时赢得一场特异性战。”
Hamish Taplin sung the praises of BEM and object-oriented principles. He raises interesting thoughts on the concept of “semantic” markup:
Hamish Taplin歌颂了BEM和面向对象的原则。 他对“语义”标记的概念提出了有趣的想法：
“The advantages of BEM were apparent immediately. Prior to adopting BEM and OOCSS principles I had been an advocate of what is (incorrectly) known as “semantic” markup. I think a lot of developers (me included) have largely misunderstood what this actually means and had been neglecting the power of classes under the guise of them not being “semantic” enough. Search engines and screen-readers don’t care about the classes you use or some extra divs used for a grid. Twitter engineer Nicholas Gallagher totally nailed this with his blog post “About HTML semantics and front-end architecture” when he says: ‘…not all semantics need to be content-derived. Class names cannot be “unsemantic”. Whatever names are being used: they have meaning, they have purpose. Class name semantics can be different to those of HTML elements.’”
“ BEM的优势立即显而易见。 在采用BEM和OOCSS原则之前，我曾倡导(错误地)称为“语义”标记的内容。 我认为许多开发人员(包括我在内)在很大程度上误解了这实际上意味着什么，并一直以他们不够“语义化”为幌子而忽略了类的功能。 搜索引擎和屏幕阅读器不在乎您使用的类或用于网格的一些额外的div。 Twitter工程师Nicholas Gallagher在他的博客文章“关于HTML语义和前端体系结构”中完全提到了这一点：“……并非所有语义都需要源自内容。 类名不能为“非语义”。 无论使用什么名称，它们都有含义，有目的。 类名的语义可以与HTML元素的语义不同。
One huge strength of BEM that a lot of the developers mention is its ability to handle developing and implementing large and modular projects in a cleaner fashion. While BEM is not only for large sites, it does appear to have great advantages in this space. Hamish discussed his experience and even has a whole blog post about it:
许多开发人员都提到BEM的一项巨大优势是其以更清洁的方式处理开发和实施大型模块化项目的能力。 尽管BEM不仅适用于大型站点，但在该领域确实具有很大的优势。 Hamish讨论了他的经验，甚至有完整的博客文章：
“I dabbled on a few small projects and got to grips with it — it was quite hard at first as it was contrary to the way I had been working for years but the benefits were becoming obvious. Then, we started on a project that was quite big and very modular in nature — My Health Skills. This was the first Bluegg project I had worked on where I was working with another developer (Paul Goodfield, who had also been using BEM) — I did the front-end and Paul the backend. The benefits were immediately obvious, Paul could understand exactly what my markup was doing and write his Laravel templates around it. If he needed to fill in some gaps then the predictable nature of BEM meant he could write the HTML just as I would have and the whole process was made much smoother. I wrote about this in a blog post “Building My Health Skills”.”
“我涉足了一些小型项目，并付诸实践-刚开始时很难，因为这与我多年来的工作方式背道而驰，但好处却越来越明显。 然后，我们开始了一个本质上非常模块化的模块化项目-我的健康技能。 这是我与另一个开发人员(也曾经使用过BEM的Paul Goodfield)一起工作的第一个Bluegg项目，我做前端，而Paul做后端。 好处立即显而易见，Paul可以完全了解我的标记在做什么，并围绕它编写Laravel模板。 如果他需要填补一些空白，那么BEM的可预测性意味着他可以像我一样编写HTML，并且整个过程变得更加流畅。 我在博客文章“建立我的健康技能”中写道。
Alec Raeside also found benefits to large projects through the modular nature of BEM naming. He says:
Alec Raeside还通过BEM命名的模块化性质为大型项目发现了好处。 他说：
“BEM is well suited to large projects. CSS is complex and large projects can fall down where unspecific selectors can cause unintended consequences elsewhere. For example, targeting all <ul>s under a selector like .container ul {} may work when that code was written, but once many other components are nested in a .container component, the ul styling may not be appropriate. With encapsulation and specificity at the heart of the BEM methodology, it can help prevent naming clashes between components and unspecific selectors from accidentally styling some of the page.
“ BEM非常适合大型项目。 CSS很复杂，大型项目可能会失败，未指定的选择器可能在其他地方导致意外的后果。 例如，在编写该代码时以.container ul {}类的选择器为目标的所有<ul>可能在编写该代码时起作用，但是一旦许多其他组件嵌套在.container组件中，则ul样式可能不合适。 BEM方法的核心是封装和特异性，它可以帮助防止组件和非特定选择器之间的命名冲突意外地样式化某些页面。
Harry Roberts, a Consultant Front-end Architect, designer and developer from the UK who has contributed a huge amount to the ideas in the area of BEM and authoring clean CSS, pointed out that the BEM methodology makes it easier to reuse components across websites through its encapsulation:
哈里·罗伯茨(Harry Roberts)是来自英国的顾问前端架构师，设计师和开发人员，他为BEM领域的思想做出了巨大贡献，并编写了清晰CSS。它的封装：
“The BEM methodology is ideally suited to projects where your components might need to be moved from one codebase to another; they need to be fully encapsulated so that you can just move one chunk of HTML, CSS, JS across to another project, and you don’t have to take any dependencies with you. Let’s imagine you work for a company that has five different sites, and they all need the same carousel on the homepage. You’d write that carousel in the BEM methodology so that you can pick it up in one piece and move it around.”
“ BEM方法学非常适合可能需要将组件从一个代码库转移到另一个代码库的项目； 它们需要完全封装，这样您就可以将HTML，CSS，JS的一部分移动到另一个项目中，而您不必带着任何依赖关系。 假设您在一家拥有五个不同站点的公司工作，并且它们都需要在首页上使用相同的轮播。 您可以使用BEM方法编写该轮播，以便可以将其拾起并四处移动。”
Josh Hunt, a front-end developer from Sydney, has found it plays nicely with other frameworks with a similar component focus:
悉尼的前端开发人员Josh Hunt发现它可以与其他具有类似组件重点的框架很好地配合使用：
“BEM does really well for sites that have lots of self-contained widgets or components, like web apps. Frameworks that promote HTML components (Angular, React, Polymer/Web Components) also make it a lot easier to apply BEM methodologies.”
“ BEM对于具有许多自包含小部件或组件(例如Web应用程序)的站点确实非常好。 促进HTML组件(Angular，React，Polymer / Web组件)的框架也使应用BEM方法更加容易。”
Bob Donderwinkel, a front-end developer from Rotterdam, the Netherlands, gave a great presentation on “The benefits of BEM CSS”. He points out the biggest advantage he found with working with BEM:
来自荷兰鹿特丹的前端开发人员Bob Donderwinkel就“ BEM CSS的好处”进行了精彩的演讲。 他指出了与BEM合作时发现的最大优势：
“I have been dabbling with BEM for half a year now and used it in two projects: a new scrolling gallery page for www.viewbook.com and reworking an old Flash site to an HTML version. The designs for these projects were well defined and I would say the biggest win using BEM was delivering a prototype fast. And that’s mainly because “deciphering” your design in Blocks, Elements, and Modifiers gives you a nice head start to code up some CSS.”
“我已经开始使用BEM半年了，并在两个项目中使用了它：用于www.viewbook.com的新滚动库页面，以及将旧的Flash网站重新制作为HTML版本。 这些项目的设计定义明确，我想说使用BEM的最大胜利就是快速交付原型。 这主要是因为在“块，元素和修饰符”中“解密”您的设计使您可以很好地开始编写一些CSS。”
Josh Hunt finds that the naming convention helps you think twice before making things too complex:
乔希·亨特(Josh Hunt)发现，命名约定可以使您在使事情变得过于复杂之前三思而后行：
“I’ve found due to the fact that it is a bit ugly, it forces you to think twice when going to write really long class names.”
“由于发现它有点丑陋，我发现它迫使您在编写非常长的类名时要三思。”
Hamish Taplin also provided these words of advice for those starting a new project:
Hamish Taplin还为那些开始新项目的人提供了以下建议：
“Have a degree of planning when you start a project. I tend to go through the mockups and look for patterns I can abstract into BEM modules. This can be hard at first but you get better at it to the point where you start to re-use old patterns. Re-using code is the nirvana of development and something your boss will thank you for when production costs go down because you’re more efficient!”
“启动项目时要有一定程度的计划。 我倾向于遍历模型并寻找可以抽象到BEM模块中的模式。 刚开始时这可能很难，但是您会在开始重新使用旧模式方面变得更好。 重复使用代码是开发的必经之路，而当您因为效率更高而降低生产成本时，老板会感谢您！”
Josh warns about getting too restrictive with your projects when aiming to use BEM:
Josh警告说，在打算使用BEM时，您的项目会变得过于严格：
“Don’t feel restricted by BEM or feel like you’re being forced to follow some weird pattern. I’m drawn to these two tweets by Harry Roberts:
“不要受到BEM的束缚，也不会觉得自己被迫遵循某种怪异的模式。 哈里·罗伯茨(Harry Roberts)吸引了我两条推文 ：
That’s not to say Modularity, DRY, SRP, etc. aren’t great ideas—they are!—but understand that they’re approaches and not achievements.
这并不是说模块化，DRY，SRP等不是好主意，而是！！但是要了解它们是方法而不是成就。
— Harry Roberts (@csswizardry) December 2, 2014
—哈里·罗伯茨(@csswizardry) 2014年12月2日
Josh explains, “BEM shouldn’t be the goal of a project, it should be something you keep in mind as you’re developing and apply where useful. Don’t get too carried away trying to stick to some theoretical ‘standard’. Helper classes (like .pull-right or .text-center) are totally cool to co-exist with BEM. Where you might have had class="story--centered", class="story text-center" will do just as well (perhaps even better).
Josh解释说：“ BEM不应成为项目的目标，在开发过程中应牢记这一点，并在有用的地方应用它。 尝试遵循一些理论上的“标准”不要太过分。 与BEM共存的辅助类(如.pull-right或.text-center )非常酷。 在您可能拥有class="story--centered" ， class="story text-center"也会做得很好(也许更好)。
Hamish didn’t take the leap into BEM straight away. It took a bit of time, an influential presentation, and changing jobs, to get him to reassess and put BEM to work on rethinking his classes. But he’s glad he did.
Hamish并没有立即进入BEM。 花了一些时间，有影响力的演讲和变动的工作，让他重新评估并让BEM着手重新考虑他的课程。 但是他很高兴自己做到了。
“I’d seen BEM mentioned a few times and thought it looked interesting but still carried on as I was, attempting to minimise the amount of markup and classes I was writing, using Sass @extend to work around the problems this causes. One day I watched Harry Roberts’ video “Breaking Good Habits” and was blown away. This guy was spot on — what problems were we actually solving by doing this?”
“我曾看到BEM提到过几次，认为它看起来很有趣，但仍然沿用至今，试图最小化我正在编写的标记和类的数量，并使用Sass @extend解决由此引起的问题。 有一天，我看了哈里·罗伯茨(Harry Roberts)的视频“打破良好习惯” ，并被吹走了。 这个家伙就在现场-我们通过这样做实际上解决了什么问题？”
Hamish goes on to say, “I was moving jobs at the time, starting at my current job at Bluegg and saw it as a clean break for trying BEM out.”
Hamish继续说：“当时，我正在转移工作，从我在Bluegg的当前工作开始，将其视为尝试BEM的绝好时机。”
I asked Harry, that same developer who blew Hamish away with his talk on “Breaking Good Habits” and who inspired Josh with his tweets, if he had any particular success stories to share. His words echoed the “give it a go” mentality:
我问哈利(同一位开发人员)，他是否分享某些成功的故事，而后者则将哈米什(Hamish)的演讲“打破美好的习惯”(Breaking Good Habits)吹走了，并通过推文启发了乔希(Josh)。 他的话呼应了“放手一搏”的心态：
“Every project I’ve worked on has benefited from the BEM naming convention. It’s not an instantly life changing thing, so it’s hard to cite success stories per se: usually it is just one of many parts that come together to create a much better whole. Like a steering wheel itself isn’t very profound, but it’s a vital part of a car; BEM naming is one thing that makes an entire project a lot better.
“我从事的每个项目都受益于BEM命名约定。 这不是改变生活的即时事物，因此很难列举成功案例本身：通常，这只是组成一个更好的整体的众多部分之一。 就像方向盘本身并不是很深刻，但它是汽车的重要组成部分。 BEM命名是使整个项目变得更好的一件事。
“The closest I have to a success story, perhaps, is the time I introduced BEM naming to a client of mine. He’d avoided BEM naming for a long, long time, citing the oft-used “But it’s just so ugly!” I convinced him to at least give it a try on a project for just half a day, and see what he thought then. He loved it. After only a few hours he was putting underscores in here, and double-hyphens in here. It’s always great to see people have that light bulb moment.”
“也许我最接近成功案例的时间是我将BEM命名引入我的客户的时间。 他避免使用BEM命名很长时间，并经常引用“这太丑了！” 我说服他至少要尝试一个项目半天，然后看看他的想法。 他喜欢它。 仅仅几个小时后，他在这里加了下划线，在这里加了双连字符。 很高兴看到人们有那个灯泡时刻。”
Harry also put the following question out there for those who are uncertain:
哈里还为不确定的人提出了以下问题：
“If you’re unsure about BEM, answer this question: What is there not to like about a strict, transparent, and meaningful way of naming things? Honestly, there are no downsides to using BEM naming.”
“如果您不确定BEM，请回答以下问题：严格，透明和有意义的命名方式有什么不喜欢的？ 坦白地说，使用BEM命名没有任何弊端。”
I’ll leave the final words on this to Hamish Taplin who said:
我将最后的话留给Hamish Taplin说：
“Just try it. BEM is about solving problems so see if it does that for you. I’ve seen it dismissed on many a forum or discussion by people who have never tried it and wish to keep their markup “semantic”. I was the same until I took the plunge and it completely changed my entire outlook on how I should write HTML and CSS. You have to be prepared to adapt and admit when you are wrong if you want to build great products.”
“去尝试一下。 BEM致力于解决问题，因此请查看它是否为您解决了问题。 我曾在许多论坛或讨论中将其拒之门外，这些人从未尝试过并且希望保持其标记“语义化”。 在尝试之前，我一直是一样的，这完全改变了我关于如何编写HTML和CSS的整个观点。 如果您想生产出优质的产品，则必须做好适应错误的准备，并接受错误的承认。”
Chris Wright, a Sydney-based developer, is a big fan of SMACSS and offered his advice. Chris’ main praise of SMACSS is the ease of use of its categorization features:
悉尼开发商Chris Wright是SMACSS的忠实拥护者，并提供了建议。 克里斯对SMACSS的主要评价是易于使用其分类功能：
“Once I started leveraging the reason why SMACSS was so powerful, the categorization features, I found it to be a really readable and teachable methodology compared with the other popular CSS methodologies.”
“一旦我开始利用SMACSS如此强大的原因，分类功能，与其他流行CSS方法相比，我发现它是一种真正易读和可教导的方法。”
“I’ve been using it as a contractor because it’s so much easier to demonstrate to people – here’s my stylesheet: classes with an l- in front of it concern layout, things with m- in front of it are modules, and so on. While I still have to handover and explain, the amount I have to explain and document has been reduced so it’s saved me more time outside of the work as well. As of last year, I’ve started using it on every project I can.”
“我一直将它用作承包商，是因为它很容易向人们演示–这是我的样式表：前面带有l-类涉及布局，前面带有m-的类是模块，依此类推。 。 虽然我仍然需要移交和解释，但是我不得不解释和记录的文件减少了，因此也节省了我更多的时间。 从去年开始，我开始在我能做的每个项目中使用它。”
Chris particularly found he had trouble getting others to work with early versions of BEM and OOCSS but SMACSS was easier to explain:
克里斯特别发现他很难让其他人使用BEM和OOCSS的早期版本，但是SMACSS更容易解释：
“I’ve found that it’s far easier to explain to a developer that’s never encountered a CSS methodology before – what the value of that methodology is and how to use it.
“我发现，向从未接触过CSS方法的开发人员解释要容易得多，该方法的价值是什么以及如何使用它。
“I tried for a while with BEM but always found people would get confused. With OOCSS I found that people’s naming conventions were often all over the place but they generally got it. SMACSS offers categorisation that helps you see straight away what the purpose of a class is.”
“我在BEM上尝试了一段时间，但总是发现人们会感到困惑。 有了OOCSS，我发现人们的命名约定通常无处不在，但他们通常都能理解。 SMACSS提供了分类，可帮助您立即了解课程的目的。”
Chris also said he found early versions of BEM to be a bit verbose but has seen it developing over time, he prefers SMACSS here.
克里斯还说，他发现早期版本的BEM有点冗长，但是随着时间的推移它在发展，他在这里更喜欢SMACSS。
“Also from a reading point of view, all those underscores and dashes and crazy long classes in BEM tended to turn me away from it – I’ve seen some more adapted versions like what Harry Roberts has done as a pretty huge improvement on the methodology, but I still don’t feel like it’s for me.
“从阅读的角度来看，BEM中的所有那些下划线，破折号和疯狂的冗长的课程往往使我远离它–我已经看到了一些更适应的版本，例如Harry Roberts所做的，作为方法学上的巨大改进，但我仍然觉得不适合我。
Chris also points out that SMACSS doesn’t need to be completely followed in the same way on larger sites compared to smaller ones, which allows for flexibility and applicability in all projects:
克里斯还指出，与较小的站点相比，在较大的站点上不需要完全遵循SMACSS，这可以在所有项目中实现灵活性和适用性：
“I think it’s safe to say varied forms of SMACSS can be suitable for all projects. As Snook states in his book – on a smaller project you probably wouldn’t use things like theme as a category (t-), but being able to differentiate a layout class from a module class from a glance is pretty valuable.”
“我认为可以肯定地说各种形式的SMACSS可以适用于所有项目。 正如Snook在书中指出的那样-在一个较小的项目中，您可能不会使用主题( t- )这样的东西，但是一眼就能将布局类与模块类区分开来非常有价值。
Hamish Taplin actually takes a hybrid approach, using some SMACSS concepts within his BEM. I found quite a few developers have found a sweet spot between the two, so it might not be a matter of choosing one over the other:
Hamish Taplin实际上采用了一种混合方法，在他的BEM中使用了一些SMACSS概念。 我发现相当多的开发人员在两者之间找到了一个完美的结合点，因此选择一个而不是另一个可能不是问题：
“I do use some SMACSS concepts and I don’t see them as mutually exclusive. I organise my Sass into “base”, “layout” and “modules” which are broadly SMACSS conventions. I’m also a big fan of using ‘state’-based classes in my JavaScript. For example, a module that can be visible or hidden might have is-visible or is-hidden classes controlled by JavaScript. I find this helps distinguish what is controlled by JavaScript rather than using BEM-style modifiers. I wouldn’t be against that though.”
“我确实使用了一些SMACSS概念，但我不认为它们是互斥的。 我将Sass组织为“基本”，“布局”和“模块”，这些基本是SMACSS约定。 我也非常喜欢在JavaScript中使用基于“状态”的类。 例如，一个可见或隐藏的模块可能具有由JavaScript控制的is-visible或is-hidden类。 我发现这有助于区分JavaScript所控制的内容，而不是使用BEM风格的修饰符。 我不会反对的。”
Bob Donderwinkel agreed that a mix of both BEM and SMACSS is possible in most situations:
鲍勃·唐德温克尔(Bob Donderwinkel)同意，在大多数情况下，可以同时使用BEM和SMACSS：
“I would say using one does not exclude the other, although there is some overlap with BEM if you consider the module and state rules from SMACSS. But besides these you can mix and match both up as needed.”
“我要说的是，使用一种方法并不能排除另一种方法，但是如果考虑SMACSS的模块和状态规则，则与BEM有一些重叠。 但是除此之外，您还可以根据需要将两者混合搭配。”
Harry Roberts recommends choosing the best bits from everywhere and uses his own methodology that he calls “ITCSS” with a combination of BEM, SMACSS, and OOCSS.
哈里·罗伯茨(Harry Roberts)建议从各处选择最好的钻头，并结合BEM，SMACSS和OOCSS使用他自己称为“ ITCSS”的方法。
“I actually use my own — as yet unpublished — ITCSS methodology alongside smatterings of OOCSS, BEM, and SMACSS. It’s hugely important to pick bits from everywhere, rather than blindly follow one methodology right to the bitter end. I always use BEM naming, and would use the BEM methodology on projects where I need fully encapsulated components that need sharing across multiple codebases. I would write these components using OOCSS, and then I would wrap these components up into an ITCSS architecture.
“我实际上使用了我自己的(尚未发布的)ITCSS方法以及少量的OOCSS，BEM和SMACSS。 从任何地方采摘比特，而不是盲目地遵循一种方法直到痛苦的结束，这一点非常重要。 我一直使用BEM命名，并且在需要完全封装的组件且需要在多个代码库之间共享的项目上使用BEM方法。 我将使用OOCSS编写这些组件，然后将这些组件包装到ITCSS架构中。
“It doesn’t start and stop with BEM and SMACSS. ITCSS is designed to encompass entire projects; OOCSS is a great little methodology that is everything-compatible; SOLID principles can be used to write better quality CSS.”
“它不会从BEM和SMACSS开始和停止。 ITCSS旨在涵盖整个项目； OOCSS是一种很棒的小方法，可以兼容所有事物。 SOLID原则可用于编写质量更高CSS。”
If you’re keen to find out a bit more on ITCSS, Harry has a a video available for you to watch. For more info on SOLID CSS principles, Harry also offered these two articles:
如果您想在ITCSS上找到更多信息，Harry会提供一个视频供您观看 。 有关SOLID CSS原理的更多信息，Harry还提供了这两篇文章：
The single responsibility principle applied to CSS
单一责任原则适用于CSS
The open/closed principle applied to CSS
适用于CSS的开放/封闭原则
Harry Roberts strongly recommends reading the SMACSS guide:
哈里·罗伯茨(Harry Roberts)强烈建议您阅读SMACSS指南 ：
“Just read up on it. SMACSS is one of the best bits of front-end reading that’s come out in the last few years, and it’s very difficult to disagree with the logic it puts forward.”
“只需阅读一下。 SMACSS是最近几年出现的最好的前端阅读工具之一，很难不同意它提出的逻辑。”
I tried to get some horror stories and words of warning from our developers – lessons we could learn from their missteps while they were in the learning process. Here are their thoughts.
我试图从开发人员那里得到一些恐怖的故事和警告语-我们可以从他们在学习过程中的失误中吸取教训。 这是他们的想法。
“It is quite a learning curve, it isn’t conceptually too difficult to understand, but it takes a while to change your habits of writing normal CSS/Sass. It’s very easy to NOT think in a purely component based way. I’ve been writing BEM all year and still feel like I’m learning and upgrading the way I write it. Sometimes you have to write a bit more CSS with BEM compared to non-BEM CSS to achieve something which is annoying, but it’s best to have consistency.
“这是一条学习曲线，从概念上讲并不是很难理解，但是要花一些时间才能改变编写普通CSS / Sass的习惯。 不以纯粹基于组件的方式思考是很容易的。 我一年来一直在写BEM，但仍然觉得自己正在学习和改进编写方式。 有时，与非BEM CSS相比，您必须用BEM写更多CSS才能达到令人讨厌的目的，但是最好具有一致性。
“BEM in itself isn’t enough to build UI the best way possible, we combine BEM, mobile first CSS, appropriate use of Sass and strict coding standards. We haven’t got it perfect but it’s getting better. We have also recently started using scss-lint to help enforce our coding standards and to a lesser extent our BEM usage.”
“ BEM本身不足以构建UI的最佳方式，我们将BEM，移动优先CSS，适当使用Sass和严格的编码标准结合在一起。 我们还没有完美的，但是它正在变得更好。 我们最近还开始使用scss-lint来帮助执行我们的编码标准，并在较小程度上帮助我们使用BEM。”
“Most of my horror stories aren’t really horror stories but places of pain. I have been encountering agencies that are really Bootstrap framework heavy who want to continue with more of an OOCSS approach, which is fine (OOCSS is pretty good too) – but trying to convince someone that uses an approach that comes with their particular framework to slightly adjust their methodology for their projects that don’t use the framework is a fairly futile argument to be having. So I have had to leave it in those cases. SMACSS’ biggest weakness I’d say is actually that it’s less widely adopted than BEM or OOCSS – it seems like fewer people have heard of it.
“我大部分的恐怖故事不是真正的恐怖故事，而是痛苦的地方。 我遇到过确实很繁琐的Bootstrap框架的代理商，他们希望继续使用更多的OOCSS方法，这很好(OOCSS也很好)–但试图说服使用特定框架随附方法的人来稍微对于不使用框架的项目调整方法，这是一个毫无用处的论点。 因此，在这些情况下，我不得不离开它。 我要说的SMACSS的最大弱点实际上是，它没有被BEM或OOCSS广泛采用-似乎听闻的人越来越少。
“My own personal stories with implementing it have been not really adhering to the point of the methodology. It’s very easy to fall in to the trap of “module all the things”, and forget that the categories that were suggested were exactly that, a suggestion. The hardest part is understanding what qualifies in each category. Is a globally used primary button a module called .m-btn-primary? Or is the thing it lives in the module? It can be confusing when you first start using methodologies, and in the case of SMACSS where you’re clearly defining things like layout, modules, and themes; I’ve run into a few situations where I had to stop and think where something belonged, but that’s also been a positive for me, and the point is we want more organised classes that people can read and understand easily.”
“我自己关于实施该方法的个人故事并没有真正坚持该方法论的观点。 很容易陷入“将所有事物模块化”的陷阱，而忘记了所建议的类别正是该建议。 最难的部分是了解每个类别的合格条件。 全局使用的主按钮是否是称为.m-btn-primary的模块？ 还是它存在于模块中？ 当您第一次开始使用方法时，以及在SMACSS中您要明确定义布局，模块和主题之类的内容时，可能会造成混淆。 我遇到了一些情况，我不得不停下来想一想什么东西应该属于什么，但这对我来说也是一个积极的方面，关键是我们希望人们可以更轻松地阅读和理解这些更有组织的课程。”
“First time using BEM will more often than not be a nightmare. My first time I was creating .classes__about__five__levels__deep. BEM is not supposed to be a one-to-one mapping of DOM structure to class names.
“第一次使用BEM通常不是一场噩梦。 我第一次创建.classes__about__five__levels__deep 。 BEM不应该是DOM结构到类名的一对一映射。
“What I’ve found difficult to apply BEM to is when you need extra elements purely for styling, like .wrapper or .inner. It’s not really right to have an .article__inner (inner isnt an element of an article). Sometimes you can be creative with the words you choose (div.article__media img.article__img), but other times it’s perfectly fine to “break” BEM and go .article-wrapper or .article-inner.
“我发现难以应用BEM的是，当您需要纯粹用于样式的其他元素时，例如.wrapper或.inner 。 拥有.article__inner (内部不是文章的元素)并不是真的正确。 有时候，您可以用自己选择的词来发挥创造力( div.article__media img.article__img )，但有时“打破” BEM并使用.article-wrapper或.article-inner 。
“I think the biggest challenge with BEM is inherent in abstraction — it can be difficult to get your head around sometimes. It requires a degree of planning to spot the patterns that can be abstracted and you sometimes end up having to refactor when you don’t spot things the first time. This is common in development though and planning and experience can help a lot.
“我认为BEM所面临的最大挑战是抽象所固有的-有时可能难以理解。 它需要进行一定程度的计划，以发现可以抽象的模式，有时，当您第一次没有发现东西时，您有时不得不进行重构。 尽管这在开发中很常见，但是规划和经验可以提供很多帮助。
“Another sticking point is that it requires total control over markup—something that can be difficult if you’re working in an environment (such as .NET) where this isn’t always possible.”
“另一个难点是，它需要对标记进行全面控制，如果您在并非总是如此的环境(例如.NET)中工作，这可能会很困难。”
“Because BEM naming is just a GoodIdea™, it’s very rare that you’ll hear any horror stories. The closest I can think of took place with a really great client of mine back at the beginning of the year. They were a really diligent team who’d done a lot of research and reading into better CSS architecture, and they got me in for a week of training to try and iron out any rough spots. One of the roughest spots was with their implementation of BEM naming. Unfortunately, they’d read an article (which, in the interests of not perpetuating, I will not link to here) that gave some really, really bad advice on BEM naming. Fundamentally flawed information that was just plain wrong. The client followed this advice to the letter and it got them into some real troubles. Things were more tangled and interconnected than ever before—something that BEM naming is meant to solve! That is, however, the only incident I am aware of.”
“由于BEM命名只是一个GoodIdea™，因此很少听到任何恐怖故事。 我能想到的最接近的事情是在今年年初与我的一个非常好的客户发生的。 他们是一个非常勤奋的团队，他们进行了大量的研究并阅读了更好CSS架构，并且让我参加了为期一周的培训，以尝试消除任何困难。 最困难的地方之一是其BEM命名的实现。 不幸的是，他们读了一篇文章(为了避免永久存在，我不会链接到这里)，该文章对BEM命名提出了一些非常非常糟糕的建议。 根本有缺陷的信息完全是错误的。 客户遵循了这封信的建议，这给他们带来了一些麻烦。 事情比以往任何时候都更加混乱和相互联系— BEM命名旨在解决这一问题！ 但是，那是我所知道的唯一事件。”
“Well I wouldn’t call it a horror story exactly ;) But I made a little BEM scaffolding tool called kaBEM. The mistake I made there was using BEM CSS class names with multiple elements (like block__element__element). Mainly because that helped in generating a nicely nested folder structure based on those CSS class names. In essence I was capturing HTML structure in CSS class names, but that actually makes BEM a little bit more rigid, which is not needed.
“好吧，我不会说这是一个恐怖的故事；)但是我制作了一个叫做kaBEM的 BEM脚手架工具。 我在那里犯的错误是使用带有多个元素的BEM CSS类名(例如block__element__element )。 主要是因为这有助于根据这些CSS类名称生成一个嵌套良好的文件夹结构。 本质上，我是在CSS类名称中捕获HTML结构，但这实际上使BEM更加僵化，这是不需要的。
“Another little gotcha was that nesting BEM CSS selectors like you can do with Sass or LESS actually adds CSS specificity where it is not needed. BEM works best as single class names, so that’s perhaps something to keep in mind.”
“另一个小问题是，像您可以使用Sass或LESS那样嵌套BEM CSS选择器实际上在不需要CSS的地方增加了CSS的特异性。 BEM最好作为单一类名，因此可能要牢记这一点。”
After going through everyone’s responses and ideas, it was clear that the best approach seemed to be a hybrid. Read up on everything, give both BEM and SMACSS a go with an open mind and see whether your CSS and workflow improve. You don’t need to choose one methodology; combine the concepts of a few methodologies into one that works for you and your team. If you need help, there are plenty of developers out there willing to share some thoughts and advice.
经过每个人的回应和想法，很明显，最好的方法似乎是一种混合方法。 仔细阅读所有内容，放开BEM和SMACSS的思路，看看CSS和工作流程是否有所改善。 您无需选择一种方法。 将几种方法论的概念结合在一起，为您和您的团队工作。 如果您需要帮助，有很多开发人员愿意分享一些想法和建议。
A very big thank you to the following developers who were kind enough to give up their time to answer my questions and share their thoughts and experiences:
非常感谢以下开发人员，他们愿意放弃他们的时间来回答我的问题，并分享他们的想法和经验：
Alec Raeside – Website, Twitter
Alec Raeside – 网站 ， Twitter
Bob Donderwinkel – Website, Twitter
Bob Donderwinkel – 网站 ， Twitter
Chris Wright – Website, Twitter
克里斯·赖特(Chris Wright)– 网站 ， Twitter
Hamish Taplin – Website, Twitter
Hamish Taplin – 网站 ， Twitter
Harry Roberts – Website, Twitter
哈里·罗伯茨– 网站 ， Twitter
Josh Hunt – Website, Twitter
Josh Hunt – 网站 ， Twitter
翻译自: https://www.sitepoint.com/bem-smacss-advice-from-developers/
bem开发模式
相关资源：jdk-8u281-windows-x64.exe