OOCSS is one of the original front-end architectures, and the initial inspiration for adding the @extend directive to Sass. A project from Nicole Sullivan, it places a strong emphasis on finding the right granularity for CSS objects, a theme that comes up in most of the systems we’ll look at here.

OOCSS是原始的前端体系结构之一，也是将@extend指令添加到Sass的最初灵感。 Nicole Sullivan的一个项目，着重强调为CSS对象找到合适的粒度 ，这是我们将在此处讨论的大多数系统中出现的主题。

Sullivan argues that rather than trying to match back-end objects, a CSS object should look for more granular design patterns that might be used across a variety of content types. A prime example is what she calls the media object—a fixed-size media element (such as an image or video) alongside fluid content such as text.

Sullivan认为，CSS对象应该尝试使用更细粒度的设计模式，这些模式可以用于多种内容类型，而不是尝试匹配后端对象。 一个典型的例子是她所说的媒体对象 -固定大小的媒体元素(例如图像或视频)以及诸如文本之类的流畅内容。

Atomic Design is also driven by questions of granularity. Initially devised by Brad Frost, an atomic project is broken down into five stages: atoms, molecules, organisms, templates, and pages. The idea is to style the stages in order, starting granular and working outwards, with each stage building on the one before.

原子设计也受粒度问题的驱动。 最初由Brad Frost设计的原子项目分为五个阶段：原子，分子，生物，模板和页面。 想法是按顺序对阶段进行样式设置，从粒状开始并向外进行，每个阶段都在之前的阶段构建。

According to Atomic Design, atoms can be abstract information such as color palettes, fonts, and typographic scales; they can also be default styles for tags such as form labels, buttons, and paragraphs. Since I can never remember the scientific terms, I break these two ideas down further and refer to the former as “configuration” or “settings” (having no output on their own), and the latter “base” or “initial” styles (having output).

根据原子设计， 原子可以是抽象信息，例如调色板，字体和印刷比例。 它们也可以是标签的默认样式，例如表单标签，按钮和段落。 由于我永远不记得科学术语，因此我将这两个想法进一步细分，将前者称为“配置”或“设置”(本身没有输出)，而后者称为“基础”或“初始”样式(有输出)。

Atoms can be put together to form molecules. Combine an image with a paragraph and button (all atoms), and you have a simple product-listing molecule. Molecules are small components that do one task well. Group a number of these molecules together, and you have an organism (in this case, a gallery of products). Organisms are larger grouped components that form a section of the interface. Your site banner might also be an organism, combining a logo, navigation, and search form. I call these next two stages “patterns” and “components,” but it’s recommended that you work with your team to find terms you all understand clearly.

原子可以放在一起形成分子 。 将图像与段落和按钮(所有原子)结合起来，您将获得一个简单的产品列表分子。 分子是完成一项任务的小组件。 将许多这些分子归为一组，就可以得到一个有机体 (在这种情况下，是一个产品库)。 有机体是组成界面一部分的较大的分组组件。 您的网站横幅也可能是有机体，结合了徽标，导航和搜索表单。 我将接下来的两个阶段称为“模式”和“组件”，但是建议您与团队合作以找到大家都清楚理解的术语。

At this point, the developers of Atomic Design abandon their biochemical analogy, and move to templates. Templates combine the smaller molecules and organisms into actual layout structures. If you run a news site, you might have a list template and a detail template for your articles. Each specific instance of a template is called a page. The home page and archive page of your news site may both use the article-list template, but they have different content. Pages are the most specific combination of all the other stages.

此时，Atomic Design的开发人员放弃了他们的生化类比，转而使用模板 。 模板将较小的分子和有机体组合成实际的布局结构。 如果您运行新闻站点，则可能有文章的列表模板和详细信息模板。 模板的每个特定实例称为页面 。 新闻站点的主页和存档页面可能都使用文章列表模板，但是它们具有不同的内容。 页面是所有其他阶段的最具体组合。

A standard Atomic Design directory will be organized into these five stage-based folders:

标准的Atomic Design目录将组织到这五个基于阶段的文件夹中：

sass/
|
|– atoms/
|   |– _colors.scss
|   |– _buttons.scss
|   …
|
|– molecules/
|   |– _navigation.scss
|   |– _search.scss
|   …
|
|– organisms/
|   |– _banner.scss
|   |– _gallery.scss
|   …
|
|– templates/
|   |– _list.scss
|   |– _detail.scss
|   …
|
|– pages/
|   |– _home.scss
|   |– _archive.scss
|   …
|
|- main.scss

Atomic Design also provides a framework called Pattern Lab. As with OOCSS, avoid confusing the framework with the design system philosophy. You can apply the philosophy anywhere, but the tools are still available if you need them. Frameworks can be a great way to keep code consistent across a large team or project, but always remember that you know your project better than Brad Frost, Nicole Sullivan, or the authors of this book. If there’s a conflict between your needs and the framework you’re using, always put your project first.

原子设计还提供了一个称为Pattern Lab的框架。 与OOCSS一样，避免将框架与设计系统哲学混淆。 您可以在任何地方应用该原理，但是如果需要，这些工具仍然可用。 框架可以是使大型团队或项目中的代码保持一致的一种好方法，但请始终记住，与Brad Frost，Nicole Sullivan或本书的作者相比，您对项目的了解要更好。 如果您的需求和使用的框架之间存在冲突，请始终将项目放在首位。

块，元素，修饰符(BEM) (Block, Element, Modifier (BEM))

BEM is a system developed by the Yandex team. This is a much more extensive system, with its fingers in every aspect of your code—from JSON data structures, to templates, as well as CSS.

BEM是Yandex团队开发的系统。 这是一个范围更广的系统，其手指遍及代码的各个方面-从JSON数据结构，模板到CSS。

The BEM CSS architecture is built around the three ideas in its title. Blocks are components of any size, and can be nested inside each other. The header block might contain a logo block, a navigation block, and a search block. Blocks are reusable, independent, and mobile—so they can be put anywhere on the page, and repeated as often as necessary. Elements are the constituent parts that belong to a specific block. A menu block might be made up of four tab elements. Modifiers are flags on blocks or elements that change their appearance, behavior, or state.

BEM CSS体系结构围绕其标题中的三个构想构建。 块是任何大小的组件，可以相互嵌套。 header块可能包含logo块， navigation块和search块。 块是可重用，独立且可移动的，因此可以将它们放置在页面上的任何位置，并根据需要重复进行。 元素是属于特定块的组成部分。 menu块可能由四个tab元素组成。 修饰符是更改其外观，行为或状态的块或元素上的标志。

The most immediately recognizable aspect of BEM syntax is an intricate naming convention that uses long class names instead of nesting selectors. Rather than targeting .block .element, you would target .block__element. There are variations on the exact syntax, but the formal documentation allow hyphens (-) within a block, element, or modifier name; double underscore (__) between block and element names; and single underscore (_) before a boolean (true/false) modifier, or between a key-value modifier name and its given value.

BEM语法最容易识别的方面是复杂的命名约定，该约定使用长类名而不是嵌套选择器。 而不是定位.block .element ，而是定位.block__element 。 确切的语法有所不同，但是正式文档允许在块，元素或修饰符名称中使用连字符( - )。 块和元素名称之间的双下划线( __ )； 在布尔值(true / false)修饰符之前或键值修饰符名称与其给定值之间加一个下划线( _ )。

Here’s an example straight from the BEM documentation that defines a form block with a _login boolean modifier, a _theme_forest key-value modifier, and two elements:

这是直接来自BEM文档的示例，该示例使用_login布尔值修饰符， _theme_forest键值修饰符和两个元素来定义form块：

<form class="form form_login form_theme_forest">
<input class="form__input">
<input class="form__submit form__submit_disabled">
</form>

A related Sass partial would look like this:

相关的Sass部分看起来像这样：

.form {}
.form_theme_forest {}
.form_login {}
.form__input {}
.form__submit {}
.form__submit_disabled {}

When BEM naming became popular, people started using the Sass parent selector (&) to automatically generate their BEM class names with less repetition in the code:

当BEM命名变得流行时，人们开始使用Sass父选择器( & )自动生成其BEM类名，并在代码中减少重复：

.form {
border: 1px solid black;
&__submit {
background-color: green;
&_disabled {
background-color: gray;
}
}
}

.form {
border: 1px solid black;
}
.form__submit {
background-color: green;
}
.form__submit_disabled {
background-color: gray;
}

On the surface, this works great—but it comes at the cost of searchability. If another developer has to find the .form__submit_disabled Sass in order to make a change, searching your Sass files for .form__submit_disabled will fail to return any results.

从表面上看，这很好用，但是却以可搜索性为代价。 如果另一个开发人员必须找到.form__submit_disabled Sass才能进行更改，则在Sass文件中搜索.form__submit_disabled将无法返回任何结果。

The BEM file structure goes beyond CSS and Sass, organizing all assets (JavaScript, CSS, images, and so on) into shared directories by block. Elements and modifiers have their own subdirectories using the same underscore-driven naming conventions:

BEM文件结构超出了CSS和Sass的范围，将所有资产(JavaScript，CSS，图像等)按块组织到共享目录中。 元素和修饰符具有自己的子目录，使用相同的下划线驱动命名约定：

blocks/
|- input/
|  |- _type/
|  |  |- input_type_search.css
|  |
|  |- __box/
|  |  |- input__box.css
|  |
|  |- input.css
|  |- input.js
|
|- button/
|  |- button.css
|  |- button.js
|  |- button.png

CSS的可扩展和模块化架构(SMACSS) (Scalable and Modular Architecture for CSS (SMACSS))

SMACSS is a book, workshop, and philosophy by Jonathan Snook. Like Atomic Design, this architecture uses five categories for organizing your CSS, except that they aren’t organized from small to large. Detailed naming patterns are provided to help keep class names consistent. It’s one of the most popular brand-name architectures, and may even be the most comprehensive.

SMACSS是Jonathan Snook的书，讲习班和哲学。 像Atomic Design一样，此体系结构使用五类来组织CSS，不同之处在于它们不是按照大小排列的。 提供了详细的命名模式以帮助保持类名的一致性。 它是最受欢迎的品牌架构之一，甚至可能是最全面的。

The five categories here are base, layout, module, state, and theme. Base rules define the default style of elements, which work similarly to the atoms of Atomic Design. Layout styles are used to break the document into sections that can contain modules, the individual components of a design. State rules define different JavaScript-dependent states for a module or layout; that is, how does it change when it is active or inactive, collapsed or expanded? Most sites have no need for themes, but they can be used to describe multiple style options for the same modules.

这里的五个类别是基础，布局，模块，状态和主题。 基本规则定义了元素的默认样式，这些元素的工作方式类似于“原子设计”的原子。 布局样式用于将文档分为可包含模块 (设计的各个组件)的部分。 状态规则为模块或布局定义了不同JavaScript相关状态； 也就是说，当它处于活动状态或非活动状态，崩溃或扩展时，它将如何变化？ 大多数站点不需要主题 ，但是它们可以用于描述同一模块的多个样式选项。

In order to help keep CSS and HTML modules small and mobile, SMACSS pays special attention to what Snook calls the depth of applicability. You may know of the Sass “inception rule,” which states that you should never nest selectors more than three layers deep. That rule helps to keep selectors short (no more than three layers), but the depth of applicability is a bit different. Rather than counting the number of layers, it counts the total DOM distance between the first and last layers.

为了使CSS和HTML模块保持小巧和可移动性，SMACSS特别注意了Snook所说的适用性 。 您可能知道Sass的“初始规则”，该规则指出，嵌套选择器的深度不得超过三层。 该规则有助于使选择器简短(不超过三层)，但是适用性的深度有所不同。 它不计算层数，而是计算第一层和最后一层之间的总DOM距离 。

Let’s look at a simple example. Since .mammalia > .primates > .hominidae > .sapiens > .rollsman > .erin has a depth of six, the same basic selector written as .mammalia .sapiens .erin would still have a depth of six. By shortening the selector, we’ve lowered the specificity (a good thing!), but we still have a large depth of applicability. The problem with so much depth is that it makes our CSS more dependent on a particular HTML structure. This is generally solved by keeping our HTML and CSS components small and independent from their containers.

让我们看一个简单的例子。 由于.mammalia > .primates > .hominidae > .sapiens > .rollsman > .erin的深度为6，因此写为.mammalia .sapiens .erin的相同基本选择器的深度仍为6。 通过缩短选择器，我们降低了特异性(这是一件好事！)，但适用范围仍然很广。 如此深入的问题在于，它使我们CSS更加依赖于特定HTML结构。 通常可以通过使我们HTML和CSS组件保持较小且独立于其容器来解决此问题。

Hugo uses a variation of SMACSS for organizing Sass partials. He calls it the “7-1” system, because it uses seven folders of partials and one master file to pull them all together.

雨果(Hugo)使用SMACSS的变体来组织Sass部分。 他称其为“ 7-1 ”系统，因为该系统使用了七个部分文件夹和一个主文件来将它们全部拉在一起。

The base/ folder contains broad standards across a site—such as a reset, default styles for common HTML tags, common animations, and basic typography. The layout folder includes everything one might need for laying out the structure of a site; for example, boilerplate-like headers, footers, and navigation, as well as your grid system and layout helpers. The components folder is organized into partials by component; the pages folder contains any page-specific styles; and a themes folder holds any theme-related styles (if your project has multiple themes).

base /文件夹包含整个站点的广泛标准，例如重置，常见HTML标签的默认样式，常见动画和基本排版。 布局文件夹包含布局网站结构可能需要的所有内容； 例如，样板样的页眉，页脚和导航，以及网格系统和布局助手。 组件文件夹按组件分为多个部分。 pages文件夹包含任何特定于页面的样式； 一个themes文件夹包含任何与主题相关的样式(如果您的项目有多个主题)。

7-1 also includes an abstracts folder for Sass tools and helpers, which is organized into partials for global variables, functions, mixins, and placeholders. Nothing in this folder should output any CSS if compiled on its own.

7-1还包括一个用于Sass工具和助手的abstracts文件夹，该文件夹被组织为局部变量，用于全局变量，函数，mixin和占位符。 如果自行编译，此文件夹中的任何内容均不应输出任何CSS。

Hugo leaves the possibility of organizing these partials by topic (typography, colors, etc.) rather than type (variables, mixins, functions) for larger projects, but I recommend that across the board. The topic is always the more important distinction in my mind. Placeholders are the only type that I treat in any special way, because their output remains in the location they are defined—while variables, functions, and mixins create output where they are used.

对于较大的项目，Hugo保留了按主题(印刷术，颜色等)而不是类型(变量，mixin，函数)组织这些部分的可能性，但我还是建议您全面使用。 在我看来，主题始终是最重要的区别。 占位符是我以任何特殊方式处理的唯一类型，因为占位符的输出保留在它们定义的位置，而变量，函数和mixins在使用它们的位置创建输出。

Finally, there is a vendors folder for third-party libraries, frameworks, and toolkits such as Normalize, Bootstrap, jQueryUI, FancyButtonsOMG, and so on. These are often kept separate so as to not edit them should they need upgrading later.

最后，还有一个供应商的第三方库，框架，以及诸如正常化，引导，jQueryUI的，FancyButtonsOMG等工具包文件夹中。 它们通常保持分开，以便以后需要升级时不进行编辑。

Put it all together, and you have a Sass directory similar to this:

放在一起，您将拥有一个类似于以下内容的Sass目录：

sass/
|
|– base/
|   |– _reset.scss       # Reset/normalize
|   |– _typography.scss  # Typography rules
|   …                    # Etc.
|
|– components/
|   |– _buttons.scss     # Buttons
|   |– _carousel.scss    # Carousel
|   |– _cover.scss       # Cover
|   |– _dropdown.scss    # Dropdown
|   …                    # Etc.
|
|– layout/
|   |– _navigation.scss  # Navigation
|   |– _grid.scss        # Grid system
|   |– _header.scss      # Header
|   |– _footer.scss      # Footer
|   …                    # Etc.
|
|– pages/
|   |– _home.scss        # Home specific styles
|   |– _contact.scss     # Contact specific styles
|   …                    # Etc.
|
|– themes/
|   |– _theme.scss       # Default theme
|   |– _admin.scss       # Admin theme
|   …                    # Etc.
|
|– utils/
|   |– _variables.scss   # Sass Variables
|   |– _functions.scss   # Sass Functions
|   |– _mixins.scss      # Sass Mixins
|   |– _helpers.scss     # Class & placeholders helpers
|
|– vendors/
|   |– _bootstrap.scss   # Bootstrap
|   |– _jquery-ui.scss   # jQuery UI
|   …                    # Etc.
|
`– main.scss             # Main Sass file

倒三角形CSS(ITCSS) (Inverted Triangle CSS (ITCSS))

ITCSS is a new architecture that is just starting to gain attention. This system from Harry Roberts does a great job defining the problem of CSS architecture and proposing a solution that comes directly out of the CSS language. Rather than working around inheritance and specificity, Roberts puts them at the center of his methodology.

ITCSS是一个刚刚开始引起关注的新体系结构。 哈里·罗伯茨 ( Harry Roberts)的这个系统在定义CSS体系结构问题和提出直接来自CSS语言的解决方案方面做得很好。 罗伯茨没有围绕继承和特殊性开展工作，而是将它们置于他的方法论的中心。

ITCSS organizes all your Sass and CSS based on three metrics: reach, specificity, and explicitness—visualized as an inverted triangle, as shown below:

ITCSS根据三个指标来组织您的所有Sass和CSS：覆盖率，特异性和明确性-可视为倒三角形，如下所示：