很多时候，我看到有人把文件分成几个部分，在部分之间加上标题注释。

类似的

/* Headings and General Text */

.... stuff here for H1, etc..

/* Main page layout */

.... stuff here for layout page setup etc.

它工作得很好，可以让你很容易回头看看你正在做什么。

以下是4个例子:

CSS约定/代码布局模型 在编写我的第一个样式表时，我应该遵循哪些CSS标准? 整理CSS的最佳方法是什么? 最佳实践- CSS样式表格式

在所有4个问题上，我的回答都包含了下载并阅读Natalie Downe的PDF CSS系统的建议。(PDF包含了大量幻灯片上没有的注释，所以请阅读PDF!)注意她对组织的建议。

四年后，我想说:

Use a CSS pre-processor and manage your files as partials (I personally prefer Sass with Compass, but Less is quite good as well and there are others) Read up on concepts like OOCSS, SMACSS, and BEM or getbem. Take a look at how popular CSS frameworks like Bootstrap and Zurb Foundation are structured. And don't discount less popular frameworks - Inuit is an interesting one but there are plenty others. Combine/minify your files with a build step on a continuous integration server and/or a task runner like Grunt or Gulp.

你应该看看边界元法。

理论

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项目变得混乱而设计。我尽量遵循其中的大部分。

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

我注意到您只使用了类标识符(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中就没有太多办法了。

我倾向于这样组织我的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写标题

只是将部分分割成文件。任何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样式表中。

原因如下:

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