你应该看看边界元法。

理论

BEM试图提供一组用于组织和命名css选择器的指令，以使选择器更具可重用性和模块化，并避免选择器之间的冲突，这种冲突通常会导致意大利面条式的代码和特定的问题。

如果正确使用，它实际上有一些非常积极的影响。

当样式被添加到元素中时，它们的作用是您所期望的 样式不会泄露，并且只影响它们所添加的内容 样式与文档结构完全解耦 不同的风格不需要被强迫凌驾于彼此之上

BEM works well with SASS to bring an almost object oriented style to CSS. You can build modular files, that handle the display of a single UI element and contain variables, such as colours and 'methods' such as how internal elements are handled. While a hardcore OO programmer might balk at this idea, in fact, the applied concepts bring in a lot of the nicer parts of OO structures, such as modularity, loose coupling and tight cohesion and context free re-usability. You can even build in a way that looks like an encapsulated object by using Sass and the & operator.

更多来自Smashing杂志的深入文章可以在这里找到;还有一个来自CCS Wizardry的Harry Roberts(任何参与css的人都应该读一下他的书)。

在实践中

我已经用过它几次了，还用过SMACSS和OOCSS，这意味着我也可以对它们进行比较。我也在一些大混乱中工作过，通常是我自己没有经验的创作。

当我在现实世界中使用BEM时，我用一些额外的原则来增强这种技术。我利用实用工具类-一个很好的例子是包装类:

.page-section {
    width: 100%;
}
@media screen and (min-width: 1200px) {
    margin: 0 auto;
    width: 1200px;
}

我也有些依赖于级联和特异性。在这里，BEM模块将是.primary-box，而.header将是特定重写的上下文

.header {
  .primary-box {
    color: #000;
  }
}

(我尽我最大的努力使所有的东西都是通用的和上下文无关的，这意味着一个好的项目几乎所有的东西都在可重用的模块中)

我想说的最后一点是，无论你的项目看起来多么小，多么简单，你都应该从一开始就这么做，原因有二:

项目越来越复杂，所以打下良好的基础是很重要的，包括CSS 即使是一个看起来很简单的项目，因为它是建立在WordPress上的，JavaScript很少，但在CSS中仍然非常复杂——好吧，你不需要做任何服务器端编码，所以这部分很简单，但是宣传册前端有20个模块和每个模块的3个变体:你有一些非常复杂的CSS !

Web组件

在2015年，我们开始关注Web组件。我对这些还不太了解，但它们希望将所有前端功能放在自包含的模块中，有效地尝试将各种原则从BEM应用到前端作为一个整体，并将分散但完全耦合的元素(如DOM片段、Js (MVC)和CSS)组合在一起，这些元素都构建相同的UI小部件。

通过这样做，他们b将解决css中存在的一些原始问题，我们试图用BEM等东西来解决这些问题，同时使其他一些前端架构更加合理。

这里有一些进一步的阅读材料，还有一个框架聚合物，非常值得一看

最后

我也认为这是一个优秀的、现代的css最佳实践指南——专门为防止大型css项目变得混乱而设计。我尽量遵循其中的大部分。

我发现最难的事情是将网站所需的设计转化为一系列规则。如果站点的设计清晰且基于规则，那么你的类名和CSS结构就可以由此而来。但是，如果人们随着时间的推移，随机地在网站上添加一些没有多大意义的内容，那么在CSS中就没有太多办法了。

我倾向于这样组织我的CSS文件:

CSS reset, based on Eric Meyer’s. (Because otherwise I find that, for most elements, I’ve got at least one or two rules that are just resetting default browser styles — most of my lists don’t look like the default HTML style for lists, for example.) Grid system CSS, if the site calls for it. (I base mine on 960.gs) Styles for components that appear on every page (headers, footers, etc) Styles for components that are used in various places across the site Styles that are only relevant on individual pages

如你所见，这主要取决于网站的设计。如果设计清晰有条理，你的CSS也可以做到。如果不是，你就完蛋了。

这是一个非常好的问题。在我所看到的任何地方，CSS文件都倾向于在一段时间后失去控制——尤其是，但不仅仅是在团队中工作时。

以下是我自己努力遵守的规则(并不是说我总能做到)。

Refactor early, refactor often. Frequently clean up CSS files, fuse together multiple definitions of the same class. Remove obsolete definitions immediately. When adding CSS during fixing bugs, leave a comment as to what the change does ("This is to make sure the box is left aligned in IE < 7") Avoid redundancies, e.g. defining the same thing in .classname and .classname:hover. Use comments /** Head **/ to build a clear structure. Use a prettifier tool that helps maintain a constant style. I use Polystyle, with which I'm quite happy (costs $15 but is money well spent). There are free ones around as well (e.g. Code Beautifier based on CSS Tidy, an open-source tool). Build sensible classes. See below for a few notes on this. Use semantics, avoid DIV soup - use <ul>s for menus, for example. Define everything on as low a level as possible (e.g. a default font family, colour and size in the body) and use inherit where possible If you have very complex CSS, maybe a CSS pre-compiler helps. I'm planning to look into xCSS for the very same reason soon. There are several others around. If working in a team, highlight the necessity of quality and standards for CSS files as well. Everybody's big on coding standards in their programming language(s), but there is little awareness that this is necessary for CSS too. If working in a team, do consider using Version Control. It makes things that much easier to track, and editing conflicts that much easier to solve. It's really worth it, even if you're "just" into HTML and CSS. Do not work with !important. Not only because IE =< 7 can't deal with it. In a complex structure, the use of !important is often tempting to change a behaviour whose source can't be found, but it's poison for long-term maintenance.

构建合理的类

这就是我喜欢构建合理类的方式。

我首先应用全局设置:

body { font-family: .... font-size ... color ... }
a { text-decoration: none; }

然后，我确定页面布局的主要部分。顶部区域、菜单、内容和页脚。如果我写了好的标记，这些区域将与HTML结构相同。

然后，我开始构建CSS类，在合理的情况下指定尽可能多的祖先，并将相关类尽可能紧密地分组。

div.content ul.table_of_contents 
div.content ul.table_of_contents li 
div.content ul.table_of_contents li h1
div.content ul.table_of_contents li h2
div.content ul.table_of_contents li span.pagenumber

你可以把整个CSS结构想象成一棵树，它的定义越远越具体。你想要尽可能地减少课程的数量，并且尽可能少地重复学习。

例如，假设您有三个级别的导航菜单。 这三个菜单看起来不同，但它们也有一些共同的特征。例如，它们都是<ul>，它们都有相同的字体大小，并且项目都是彼此相邻的(与ul的默认呈现相反)。此外，所有菜单都没有项目符号(list-style-type)。

首先，在一个名为menu的类中定义公共特征:

div.navi ul.menu { display: ...; list-style-type: none; list-style-image: none; }
div.navi ul.menu li { float: left }

然后，定义这三个菜单的具体特征。第1级是40像素高;2级和3级，20像素。

注意:您也可以为此使用多个类，但Internet Explorer 6在使用多个类时存在问题，因此本例使用id。

div.navi ul.menu#level1 { height: 40px; }
div.navi ul.menu#level2 { height: 20px; }
div.navi ul.menu#level3 { height: 16px; }

菜单的标记看起来像这样:

<ul id="level1" class="menu"><li> ...... </li></ul>
<ul id="level2" class="menu"><li> ...... </li></ul>
<ul id="level3" class="menu"><li> ...... </li></ul>

如果页面上有语义相似的元素(比如这三个菜单)，首先试着找出共性，然后把它们放到一个类中;然后，计算出特定的属性并将它们应用到类中，或者，如果您必须支持Internet Explorer 6，则应用ID。

其他HTML技巧

如果你将这些语义添加到HTML输出中，设计师以后可以使用纯CSS定制网站和/或应用程序的外观，这是一个很大的优势和节省时间。

If possible, give every page's body a unique class: <body class='contactpage'> this makes it very easy to add page-specific tweaks to the style sheet: body.contactpage div.container ul.mainmenu li { color: green } When building menus automatically, add as much CSS context as possible to allow extensive styling later. For example: <ul class="mainmenu"> <li class="item_first item_active item_1"> First item </li> <li class="item_2"> Second item </li> <li class="item_3"> Third item </li> <li class="item_last item_4"> Fourth item </li> </ul> This way, every menu item can be accessed for styling according to its semantic context: Whether it's the first or last item in the list; Whether it's the currently active item; and by number.

请注意，如上例中所述的多个类的分配在IE6中不能正常工作。有一个变通方案可以使IE6能够处理多个类。如果没有解决方法，则必须设置对您来说最重要的类(项目编号、活动或第一个/最后一个)，或者使用id。

您还应该了解级联、权重以及它们是如何工作的。

我注意到您只使用了类标识符(div.title)。您知道您也可以使用ID，而且ID比类更重要吗?

例如,

#page1 div.title, #page1 ul, #page1 span {
  // rules
}

将使所有这些元素共享一个字体大小，或者颜色，或者任何你的规则。您甚至可以使所有的div都是#page1的后代获得某些规则。

至于重量，请记住CSS轴从最一般/最轻到最特定/最重。也就是说，在CSS选择器中，一个元素说明符被一个类说明符取代，一个ID说明符取代。数字计数，因此具有两个元素说明符(ul li)的选择器将比只有一个说明符(li)的选择器具有更大的权重。

把它想象成数字。个位上的9仍然小于十位上的1。一个有ID说明符、一个类说明符和两个元素说明符的选择器，将比没有ID、500个类说明符和1000个元素说明符的选择器具有更大的权重。当然，这是一个荒谬的例子，但你可以理解。关键是，应用这个概念可以帮助您清理大量CSS。

顺便说一句，在类中添加元素说明符(div.title)是没有必要的，除非你遇到了与其他具有class="title"的元素冲突。不要增加不必要的重量，因为你以后可能会用到这些重量。

不要用CSS写标题

只是将部分分割成文件。任何CSS注释，都应该是注释。

reset.css
base.css
somepage.css
someotherpage.css
some_abstract_component.css

使用脚本将它们合并为一个;如果有必要的话)。您甚至还可以拥有一个漂亮的目录结构，只需让脚本递归地扫描.css文件。

如果你必须写标题，在文件的开头有一个TOC

TOC中的标题应该与您稍后编写的标题完全相同。搜索标题是件痛苦的事。更麻烦的是，人们怎么知道在第一个头文件之后还有另一个头文件呢?注:写toc时不要在每行开头加上类似doc的*(星号)，这只会让选择文本变得更烦人。

/* Table of Contents
   - - - - - - - - -
   Header stuff
   Body Stuff
   Some other junk
   - - - - - - - - -
 */
...
/* Header Stuff 
 */
...
/* Body Stuff 
 */

使用规则或在规则内编写注释，而不是在块之外

首先，当您编辑脚本时，有50%的几率您会注意到规则块之外的内容(特别是如果它是一大块文本;))。其次，(几乎)不需要在外部添加“注释”。如果是在室外，那么99%的情况下都是游戏，所以保持这种状态。

将页面拆分为多个组件

组件应该有位置:相对的，没有填充和空白，大多数时候。这大大简化了%规则，并且允许更简单的元素的绝对:位置，因为如果有一个绝对定位的容器，绝对定位的元素将在计算上、右、下、左属性时使用容器。

HTML5文档中的大多数div通常都是一个组件。

组件也可以被认为是页面上的一个独立单元。用门外汉的话说，如果把一个东西当作一个黑盒是有意义的，那么就把它当作一个组件。

还是以QA页面为例:

#navigation
#question
#answers
#answers .answer
etc.

通过将页面划分为组件，您可以将工作划分为可管理的单元。

将具有累积效果的规则放在同一行上。

例如，边框、边距和填充(但不包括轮廓)都会增加你要样式化的元素的尺寸和大小。

position: absolute; top: 10px; right: 10px;

如果它们在一行中没有那么好读，至少把它们放在很近的地方:

padding: 10px; margin: 20px;
border: 1px solid black;

尽可能使用速记:

/* the following... */
padding-left: 10px;
padding-right: 10px;
/* can simply be written as */
padding: 0 10px;

不要重复选择器

如果您有同一个选择器的多个实例，那么很有可能最终会不可避免地得到相同规则的多个实例。例如:

#some .selector {
    margin: 0;
    font-size: 11px;
}
...
#some .selector {
    border: 1px solid #000;
    margin: 0;
}

当可以使用id/classes时，避免使用TAGs作为选择符

首先，DIV和SPAN标签是个例外:永远不要使用它们!,)只使用它们来附加类/id。

这个…

div#answers div.answer table.statistics {
    border-collapse: collapsed;
    color: pink;
    border: 1px solid #000;
}
div#answers div.answer table.statistics thead {
    outline: 3px solid #000;
}

应该这样写:

#answers .answer .statistics {
    border-collapse: collapsed;
    color: pink;
    border: 1px solid #000;
}
#answers .answer .statistics thead {
    outline: 3px solid #000;
}

因为额外悬挂的div没有给选择器添加任何东西。它们还强制使用不必要的标签规则。例如，如果您要将.answer从一个div更改为一篇文章，那么您的风格就会中断。

或者如果你喜欢更清晰的表述:

#answers .answer .statistics {
    color: pink;
    border: 1px solid #000;
}
#answers .answer table.statistics {
    border-collapse: collapsed;
}
#answers .answer .statistics thead {
    outline: 3px solid #000;
}

原因是border-collapse属性是一个特殊的属性，只有应用于表时才有意义。如果.statistics不是一个表，它就不应该应用。

通用规则是邪恶的!

如果可以的话，避免编写通用的/神奇的规则 除非是css重置/取消重置，否则你所有的通用魔法应该至少适用于一个根组件

他们不会节省你的时间，他们会让你的头爆炸;同时也使维护成为噩梦。当你在编写规则时，你可能知道它们应用在哪里，但这并不能保证你的规则以后不会给你带来麻烦。

除此之外，通用规则令人困惑且难以阅读，即使您对正在设置样式的文档有所了解。这并不是说你不应该写泛型规则，只是不要使用它们，除非你真的想让它们是泛型的，即使它们在选择器中添加了尽可能多的作用域信息。

像这样的事情……

.badges {
    width: 100%;
    white-space: nowrap;
}

address {
    padding: 5px 10px;
    border: 1px solid #ccc;
}

.．.与在编程语言中使用全局变量有相同的问题。你需要给他们空间!

#question .userinfo .badges {
    width: 100%;
    white-space: nowrap;
}

#answers .answer .userinfo address {
    padding: 5px 10px;
    border: 1px solid #ccc;
}

这句话的大意是:

components                   target
---------------------------- --------
#answers .answer   .userinfo address
-------- --------- --------- --------
domain   component component selector 

当我知道一个组件是页面上的单例时，我喜欢使用id;你的需求可能不同。

注意:理想情况下，你应该写足够的内容。然而，在选择器中提到更多的组件相比于提到更少的组件是一个更宽容的错误。

让我们假设您有一个分页组件。您可以在站点的许多地方使用它。这将是编写通用规则的一个很好的例子。让我们假设你显示:阻止单个页码链接，并给它们一个深灰色的背景。为了让它们可见，你必须有这样的规则:

.pagination .pagelist a {
    color: #fff;
}

现在让我们假设你使用你的页码来做一个答案列表，你可能会遇到这样的事情

#answers .header a {
    color: #000;
}
...
.pagination .pagelist a {
    color: #fff;
}

这将使你的白色链接变黑，这是你不想要的。

不正确的解决方法是:

.pagination .pagelist a {
    color: #fff !important;
}

正确的解决方法是:

#answers .header .pagination .pagelist a {
    color: #fff;
}

复杂的“逻辑”评论不起作用:)

如果你这样写:“this value is dependent on blah-blah and height of blah-blah”，这是不可避免的，你会犯错误，它会像纸牌屋一样倒塌。

保持你的评论简单;如果你需要“逻辑操作”，考虑一种CSS模板语言，比如SASS或LESS。

我怎么写一个颜色托盘?

把这个留到最后。为你的整个色盘准备一个文件。如果没有这个文件，你的样式在规则中仍然有一些可用的颜色托盘。您的颜色托盘应该覆盖。你使用一个非常高级的父组件(例如。#page)，然后把你的风格写成一个自给自足的规则块。它可以只是颜色或更多的东西。

eg.

#page #header .description,
#page #categories .description,
#page #answers .answer .body
{
    color: #222; background: #fff; 
    border-radius: 10px;
    padding: 1em;
}

这个想法很简单，你的颜色托盘是一个独立于基本样式的样式表，你可以级联到它。

更少的名称，需要更少的内存，使代码更容易阅读

名字越少越好。理想情况下，使用非常简单(并且简短!)的单词:文本，正文，标题。

我还发现简单单词的组合比一堆“合适”的长单词(postbody, posthead, userinfo等)更容易理解。

保持词汇量小，这样即使有陌生人进来阅读你的风格汤(比如几周后的你;))，只需要知道单词在哪里使用，而不是每个选择器在哪里使用。例如，每当一个元素被认为是“所选项目”或“当前项目”时，我就使用。this。

自己清理干净

写CSS就像吃东西，有时你会留下一团乱。确保您清理了这些混乱，否则垃圾代码就会堆积起来。删除你不使用的类/id。删除你不使用的CSS规则。确保一切都很好，你没有冲突或重复的规则。

如果您像我建议的那样，在您的风格中将一些容器视为黑盒(组件)，在选择器中使用这些组件，并将所有内容保存在一个专用文件中(或使用TOC和头文件正确地分割为一个文件)，那么您的工作基本上会更容易……

您可以使用工具，如firefox扩展Dust-Me Selectors(提示:指向您的sitemap.xml)来帮助您找到一些隐藏在css nukes和carnies中的垃圾。

保持一个未排序的。css文件

假设您正在设计一个QA站点，并且已经有了“答案页面”的样式表，我们将其称为answers.css。如果你现在需要添加很多新的css，将其添加到unsorted.css样式表中，然后重构到answers.css样式表中。

原因如下:

在完成之后进行重构更快，然后搜索规则(可能不存在)并注入代码 你会写一些你要删除的东西，注入代码只会让你更难删除这些代码 附加到原始文件很容易导致重复规则/选择器

我的回答是高水平的，针对你刚才提到的高水平的关切。也许你可以通过一些低级的组织技巧和调整来使它更漂亮，但这些都不能解决方法上的缺陷。有几个因素会影响CSS的爆炸。显然是网站的整体复杂性，但还有像命名语义、CSS性能、CSS文件组织和可测试性/可接受性等问题。

在命名语义方面，您似乎走在了正确的道路上，但还可以更进一步。重复出现在站点上而没有进行结构修改的HTML部分(称为“模块”)可以被视为选择器根，从那里您可以相对于根确定内部布局的范围。这是面向对象的CSS的基本原则，您可以在Yahoo工程师的演讲中阅读/观看更多关于它的内容。

需要注意的是，这种干净的方法可能与性能问题相反，它倾向于基于id或标记名的短选择器。找到平衡取决于你，但除非你有一个庞大的网站，这应该只是一个指南在你的脑后提醒你保持你的选择器简短。这里有更多关于性能的信息。

最后，您将为整个网站使用一个CSS文件，还是多个文件(单个基本文件用于每个页面或-section文件)?单个文件对于性能来说更好，但是对于多个团队成员来说可能更难理解/维护，并且可能更难测试。对于测试，我建议您使用一个CSS测试页面，其中包含所有受支持的CSS模块，以测试冲突和意外级联。

或者，您也可以采用多文件方法，将CSS规则作用于一个页面或一个部分。这需要浏览器下载多个文件，这是一个性能问题。您可以使用服务器端编程动态地指定和聚合(并缩小)CSS文件到单个文件中。但是，由于这些文件是分开的，对它们的测试也是分开的，因此可能会在页面/部分之间引入不一致的外观。因此测试变得更加困难。

由你来分析客户的具体需求，并相应地平衡这些问题。