我一直非常依赖CSS来处理我正在开发的网站。现在，所有的CSS样式都是基于每个标签应用的，所以现在我试图将它移动到更多的外部样式，以帮助进行任何未来的更改。

但现在问题是我注意到我正在进行"CSS爆炸"。我很难决定如何在CSS文件中最好地组织和抽象数据。

我在网站中使用了大量的div标签，从一个基于表格的网站上移动。所以我得到了很多看起来像这样的CSS选择器：

这还不算太糟糕，但由于我是初学者，我想知道是否可以就如何最好地组织CSS文件的各个部分提出建议。我不想为我网站上的每个元素都有一个单独的CSS属性，而且我总是希望CSS文件相当直观且易于阅读。

我的最终目标是使CSS文件易于使用并展示其提高Web开发速度的能力。这样，将来可能在这个网站上工作的其他人也会参与使用良好编码实践的做法，而不是像我那样去做。

---

这个问题问得好。我看到的每个地方，CSS文件都会在一段时间后失控 - 特别是，但不仅仅是在团队中工作时。

以下是我自己想要遵守的规则(而不是我一直坚持的规则。)

经常重构，重构。经常清理CSS文件，将同一类的多个定义融合在一起。立即删除过时的定义。

在修复错误期间添加CSS时，请对更改的内容发表评论("这是为了确保该框在IE <7中保持对齐")

避免冗余，例如在.classname和.classname:hover中定义相同的内容。

使用注释/** Head **/构建清晰的结构。

使用有助于保持恒定风格的美化工具。我使用的是Polystyle，我很高兴(花费15美元，但花钱很好)。我确信周围也有免费的(更新：例如基于CSS Tidy的Code Beautifier，一个开源工具，我还没有使用过，但看起来非常有趣。)

建立合理的课程。请参阅下面的一些注释。

使用语义，避免DIV汤 - 例如，使用

s作为菜单。

将所有内容定义在尽可能低的级别(例如，body中的默认字体系列，颜色和大小)，并尽可能使用inherit

如果你有非常复杂的CSS，也许CSS预编译有帮助。我打算很快调查xCSS。还有其他几个。

如果在团队中工作，也要强调CSS文件的质量和标准的必要性。每个人都对编程语言的编码标准很重要，但很少有人意识到这也是CSS所必需的。

如果在团队中工作，请考虑使用版本控制。它使事情更容易跟踪，编辑冲突更容易解决。它真的很值得，即使你只是"只是"HTML和CSS。

不使用!important。不仅因为IE = <7无法处理它。在一个复杂的结构中，使用！important通常很容易改变无法找到源的行为，但它对于长期维护是有害的。

建立合理的课程

这就是我喜欢建立合理课程的方式。

我首先应用全局设置：

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

然后，我开始构建CSS类，尽可能多地指定祖先和合理，并尽可能地将相关类分组。

将整个CSS结构想象成一棵树，具有越来越具体的定义，离你的根越远。您希望尽可能减少类的数量，并且您希望尽可能少地重复自己。

例如，假设您有三个级别的导航菜单。
这三个菜单看起来不同，但它们也具有某些特征。例如，它们都是

，它们都具有相同的字体大小，并且这些项目彼此相邻(与ul的默认呈现相反)。此外，没有菜单有任何项目符号(list-style-type)。

首先，将公共特征定义为名为menu的类：

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

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

菜单的标记如下所示：

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

其他HTML提示

If you add these semantics into your HTML output, designers can later customize the look of web sites and/or apps using pure CSS, which is a great advantage and time-saver.

Ok.

如果可能的话，给每个页面的主体一个唯一的类：这使得在样式表中添加特定于页面的调整变得非常容易：

1	body.contactpage div.container ul.mainmenu li { color: green }

在自动构建菜单时，尽可能多地添加CSS上下文，以便以后进行广泛的样式设置。例如：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

<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>   </p>Ok.

这样，每个菜单项都可以根据其语义上下文进行样式访问：它是列表中的第一个还是最后一个项目;是否是当前活动的项目;并按数字。

Note that this assigning of multiple classes as outlined in the example above does not work properly in IE6. There is a workaround to make IE6 able to deal with multiple classes; I haven't tried it yet but looks very promising, coming from Dean Edwards. Until then, you will have to set the class that is most important to you (item number, active or first/last) or resort to using IDs. (booo IE6!)

Ok.

好。

---

这里只有4个例子：

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

在所有4个答案中，我的答案包括下载和阅读Natalie Downe的PDF CSS Systems的建议。 (PDF包含幻灯片中没有的大量笔记，因此请阅读PDF！)。记下她对组织的建议。

编辑(2014/02/05)四年后，我会说：

• 使用CSS预处理器并将文件管理为部分(我个人更喜欢使用指南针的Sass，但是Less也很好，还有其他的)
• 阅读OOCSS，SMACSS和BEM或getbem等概念。
• 看一下像Bootstrap和Zurb Foundation这样流行的CSS框架是如何构建的。并且不要打折不那么受欢迎的框架 - 因纽特人是一个有趣的框架，但还有很多其他框架。
• 通过持续集成服务器和/或Grunt或Gulp等任务运行器上的构建步骤来合并/缩小文件。

---

不要在CSS中写标题

只需将部分拆分成文件即可任何CSS评论，应该只是评论。

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

如果您必须编写标题，请在文件的开头添加TOC

TOC中的标题应该与您稍后写的标题完全相同。寻找标题真是太痛苦了。要添加问题，在第一个标题后，有多人认为你知道你有另一个标题？ PS。在编写TOC时，不要在每行的开头添加doc-like *(star)，这只会让选择文本更加烦人。

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

首先，当您编辑脚本时，有50/50的机会您将注意规则块之外的内容(特别是如果它是一个大的文本块;))。其次，(几乎)没有你需要在外面"评论"的情况。如果它在外面，它是99％的时间标题，所以保持这样。

将页面拆分为组件

组件在大多数情况下应该具有position:relative，no padding和no margin。这大大简化了％规则，并允许更简单的absolute:position'元素，因为如果有一个绝对定位的容器，绝对定位元素将在计算top，right，bottom时使用容器，left属性。

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

组件也可以被视为页面上的独立单元。在非专业人士的术语中，如果对待像黑盒子这样的东西是有意义的，那就把它当成一个组件。

再次使用QA页面示例：

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

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

例如，border，margin和padding(但不是outline)都会添加到要样式化的元素的尺寸和大小。

如果它们在一条线上不可读，至少将它们放在一起：

尽可能使用速记：

不要重复选择器

如果你有相同选择器的更多实例，那么你很可能不可避免地会遇到相同规则的多个实例。例如：

当您可以使用id / classes时，避免使用TAG作为选择器

首先关闭DIV和SPAN标签是例外：永远不要使用它们！ ;)只使用它们来附加一个类/ id。

这个...

应该这样写：

因为那里额外的悬空DIV不会给选择器增加任何东西。它们还强制执行不必要的标记规则。如果您要将.answer从div更改为article，您的样式将会中断。

或者如果您希望更清晰：

原因是border-collapse属性是一个特殊属性，只有在应用于table时才有意义。如果.statistics不是table则不应用。

通用规则是邪恶的！

如果可以，请避免编写通用/魔法规则

除非是CSS重置/未设置，否则所有通用魔法应该适用于至少一个根组件

它们不会节省你的时间，它们会使你的头发爆炸;以及使维护成为一场噩梦。当你编写规则时，你可能知道它们适用的地方，但是不能保证你的规则不会在以后弄乱你。

添加到这个通用规则是令人困惑和难以阅读的，即使您对您正在构建的文档有所了解。这并不是说您不应该编写通用规则，只是不要使用它们，除非您真正想要它们是通用的，甚至它们尽可能多地将范围信息添加到选择器中。

像这样的东西......

...与在编程语言中使用全局变量具有相同的问题。你需要给他们范围！

基本上读作：

每当我知道的组件是页面上的单例时，我喜欢使用ID;你的需求可能会有所不同。

注意：理想情况下，你应该写得足够好。然而，与提及较少的组件相比，在选择器中提及更多组件是更容易犯的错误。

让我们假设你有一个pagination组件。您可以在整个网站的许多地方使用它。这将是您编写通用规则的一个很好的例子。让我们说display:block单个页码链接并给它们一个深灰色背景。要让它们可见，你必须有这样的规则：

现在假设您使用分页列表作为答案，您可能会遇到类似这样的事情

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

修复它的错误方法是：

解决问题的正确方法是：

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

如果你写下这样的话："这个价值取决于等等等等等等等等，那就不可避免地会犯错误而且它会像纸牌屋一样掉下来。

保持简单的评论;如果您需要"逻辑运算"，请考虑其中一种CSS模板语言，如SASS或LESS。

你怎么写一个彩色托盘？

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

例如。

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

名称越少，内存越少，代码越容易阅读

使用较少的名称更好。理想情况下使用非常简单(和简短！)的单词：text，body，header。

我还发现简单单词的组合更容易理解，然后有一个长"适当"的词：postbody，posthead，userinfo等。

保持词汇量小，即使有些陌生人进来阅读你的风格汤(比如几周之后你自己);这只需要了解使用单词的地方而不是每个选择器的使用位置。例如，每当元素被称为"所选项目"或"当前项目"时，我都会使用.this等。

自己清理干净

编写CSS就像吃东西，有时你会留下一团糟。确保你清理那个烂摊子，否则垃圾代码会堆积起来。删除您不使用的类/ ID。删除不使用的CSS规则。确保一切都很好，你没有冲突或重复的规则。

如果您按照我的建议将某些容器视为您的样式中的黑盒子(组件)，在选择器中使用这些组件，并将所有内容保存在一个专用文件中(或者使用TOC和标头正确拆分文件)，然后工作大大简化......

您可以使用firefox扩展Dust-Me Selectors等工具(提示：将其指向您的sitemap.xml)，以帮助您找到隐藏在您的css核武器和狂欢中的一些垃圾。

保留unsorted.css文件

假设您正在为QA网站设计样式，并且您已经有了"答案页面"的样式表，我们将其称为answers.css。如果您现在需要添加大量新css，请将其添加到unsorted.css样式表中，然后重构到answers.css样式表中。

有几个原因：

在你完成后重构更快，然后搜索规则(可能不存在)并注入代码

您将编写要删除的内容，注入代码会使删除该代码变得更加困难

附加到原始文件很容易导致规则/选择器重复

好。

---

看一下
1. SASS
指南针

---

我看到反击CSS膨胀的最好方法是使用面向对象的CSS原则。

甚至还有一个非常好的OOCSS框架。

一些意识形态与顶部答案中的许多内容相悖，但是一旦你知道如何以面向对象的方式构建CSS，你会发现它实际上可以保持代码精益和意味着。

这里的关键是在您的站点和架构师中识别"对象"或构建块模式。

Facebook聘请了OOCSS的创建者Nicole Sullivan为他们的前端代码(HTML / CSS)节省了大量资金。是的，您实际上不仅可以在CSS中获得节省，而且在您的HTML中也可以获得节省，当您提到将基于table的布局转换为大量div时，您可能会听到它的声音。

另一个很好的方法在某些方面与OOCSS类似，就是从一开始就规划和编写CSS，使其可扩展和模块化。 Jonathan Snook撰写了一篇关于SMACSS的精彩文章和书籍/电子书 - CSS的可扩展和模块化架构

让我联系你一些链接：
大规模CSS的5个错误 - (视频)
大规模CSS的5个错误 - (幻灯片)
CSS Bloat - (幻灯片)

---

您还应该了解级联，重量以及它们的工作原理。

我注意到你只使用类标识符(div.title)。您是否知道您也可以使用ID，并且ID比类更重要？

例如，

将使所有这些元素共享字体大小，比如或颜色，或任何规则。你甚至可以让所有作为＃page1后代的DIV获得一定的规则。

至于重量，请记住CSS轴从最普通/最轻到最特定/最重。也就是说，在CSS选择器中，由类说明符推翻的元素说明符被ID说明符否决。数字计数，因此具有两个元素说明符(ul li)的选择器将比仅具有单个说明符(li)的选择器具有更多权重。

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

顺便说一句，除非你遇到与class ="title"的其他元素发生冲突，否则不必将元素说明符添加到类(div.title)中。不要添加不必要的重量，因为您可能需要稍后使用该重量。

---

我可以建议Less CSS动态框架

它类似于前面提到的SASS。

它有助于维护每个父类的CSS。

例如。

这是做什么的：
对＃child1和＃child2应用宽度：100％。

此外，＃child1特定CSS属于#parent。

这将呈现给

---

我发现困难的事情是将网站所需的设计转换为一系列规则。如果网站的设计清晰且基于规则，那么您的类名和CSS结构可以从中流出。但是，如果人们随着时间的推移，随意地向网站添加一些没有多大意义的内容，那么在CSS中你可以做很多事情。

我倾向于组织我的CSS文件大致如下：

CSS重置，基于Eric Meyer的。 (因为我发现，对于大多数元素，我至少有一两个规则只是重置默认的浏览器样式 - 例如，我的大多数列表看起来都不像列表的默认HTML样式。)

网格系统CSS，如果站点要求它。 (我的基础是960.gs)

每个页面上显示的组件样式(页眉，页脚等)

在整个站点的各个位置使用的组件的样式

仅与单个页面相关的样式

如您所见，大部分内容取决于网站的设计。如果设计清晰有序，那么你的CSS就可以了。如果没有，你就搞砸了。

---

我的答案是高级别的，以解决您在问题中提出的高级别问题。可能会有低级别的组织技巧和调整，你可以做的更漂亮，但没有一个可以解决方法上的缺陷。有几件事会影响CSS爆炸。显然，网站的整体复杂性，还有命名语义，CSS性能，CSS文件组织和可测试性/可接受性等。

您似乎在使用命名语义的正确路径上，但它可以更进一步。在没有结构修改的情况下在网站上重复出现的HTML部分(称为"模块")可以被视为选择器根，从那里您可以将内部布局相对于该根进行范围。这是面向对象CSS的基本原则，您可以在雅虎工程师的演讲中阅读/观看更多相关内容。

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

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

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

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

---

如前所述：进入OOCSS。 Sass / Less / Compass很有吸引力，但在使用vanilla CSS之前，Sass / Less / Compass只会让事情变得更糟。

首先，阅读有关高效的CSS。试试Google Page Speed并阅读Souders撰写的有关高效css的文章。

然后，输入OOCSS。

• 学习使用级联。 (毕竟，我们称之为Cascading Stylesheets)。
• 了解如何正确获取粒度(自下而上而不是自上而下)
• 学习如何分离结构和皮肤(什么是独特的，以及这些对象的变化是什么？)
• 了解如何分隔容器和内容。
• 学会爱网格。

它将彻底改变关于编写CSS的每一点。我完全更新并喜欢它。

更新：SMACSS类似于OOCSS，但一般来说更容易适应。

---

从CSS Refactoring中提取的敏感CSS的核心原则：从仅附加到模块化CSS

Write in SASS. You'd be insane to forego the advantages of variables, mixins, and so on.

Never use an HTML ID for styling; always use classes. HTML IDs, when used correctly, appear only once in the whole page, which is the
complete opposite of re-usability — one of the most basic goods in
sensible engineering. Moreover, it's really hard to override selectors
containing IDs and often the only way to overpower one HTML ID is to
create another ID, causing IDs to propagate in the codebase like the
pests they are. Better to leave the HTML IDs for unchanging Javascript
or integration test hooks.

Name your CSS classes by their visual function rather than by their application-specific function. For example, say".highlight-box"
instead of".bundle-product-discount-box". Coding in this way means
that you can re-use your existing style-sheets when you role out
side-businesses. For example, we started out selling law notes but
recently moved into law tutors. Our old CSS classes had names like
".download_document_box", a class name that makes sense when talking
about digital documents but would only confuse when applied to the new
domain of private tutors. A better name that fits both existing
services — and any future ones — would be".pretty_callout_box".

Avoid naming CSS classes after specific grid information. There was (and still is) a dreadful anti-pattern in CSS communities whereby
designers and creators of CSS frameworks (cough Twitter Bootstrap)
believe that"span-2" or"cols-8" are reasonable names for CSS
classes. The point of CSS is to give you the possibility to modify
your design without affecting the markup (much). Hardcoding grids
sizes into the HTML thwarts this goal, so it is advised against in any
project expected to last longer than a weekend. More on how we avoided
grid classes later.

Split your CSS across files. Ideally you would split everything into"components"/"widgets" and then compose pages from these atoms of
design. Realistically though, you'll notice that some of your website
pages have idiosyncrasies (e.g. a special layout, or a weird photo
gallery that appears in just one article). In these cases you might
create a file related to that specific page, only refactoring into a
full-blown widget when it becomes clear that the element will be
re-used elsewhere. This is a tradeoff, one that is motivated by
practical budgetary concerns.

Minimise nesting. Introduce new classes instead of nesting selectors. The fact that SASS removes the pain of repeating selectors
when nesting doesn't mean that you have to nest five levels deep.
Never over-qualify a selector (e.g. don't use"ul.nav" where".nav"
could do the same job.) And don't specify HTML elements alongside the
custom class name (e.g."h2.highlight"). Instead just use the class
name alone and drop the base selector (e.g. the previous example
should be".highlight"). Over-qualifying selectors doesn't add any
value.

Create styles for HTML elements (e.g."h1") only when styling base components which should be consistent in the whole application.
Avoid broad selectors like"header ul" because it's likely that you
have to override them in some places anyway. As we keep saying, most
of the time you want to use a specific, well-named class whenever you
want a particular style.

Embrace the basics of Block-Element-Modifier. You can read about it for example on here. We used it quite lightly, but still it helped
us a lot in organising CSS styles.

---

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

就像是

它工作得非常好，可以让以后轻松返回并查找您正在处理的内容。

---

你应该看看BEM。

理论

BEM试图提供一组用于组织和命名css选择器的指令，以试图使事物更易于重复使用和模块化，并避免经常导致意大利面条代码和特异性问题的选择器之间的冲突。

当它被正确使用时，它实际上有一些非常积极的效果。

• 样式在添加到元素时会按预期执行
• 样式不会泄漏，只影响它们添加的内容
• 样式与文档结构完全分离
• 样式不需要被迫相互覆盖

BEM与SASS配合使用可为CSS带来几乎面向对象的风格。您可以构建模块化文件，这些文件处理单个UI元素的显示并包含变量，例如颜色和"方法"，例如如何处理内部元素。事实上，虽然硬核OO程序员可能会对这个想法不以为然，但应用概念带来了OO结构的许多更好的部分，例如模块化，松散耦合和紧密内聚以及无上下文的可重用性。您甚至可以使用Sass和&运算符以类似于封装对象的方式构建。

可以在这里找到Smashing Magazine的更深入的文章; CCS Wizardry的Harry Roberts(参与css的任何人都应该阅读)中的一个就在这里。

在实践中

我已经多次使用过这个，并且使用过SMACSS和OOCSS意味着我也有一些东西可以比较它们。我也经历过一些大的混乱，通常是我自己的，没有经验的创作。

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

而且我也在某种程度上依赖于级联和特异性。这里BEM模块将是.primary-box，.header将是特定覆盖的上下文

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

我在这里要说的最后一点是，无论你的项目是多么小而且不复杂，你应该从一开始就这样做，原因有两个：

• 项目的复杂性增加，所以奠定良好的基础很重要，包括css
• 即使是一个看起来很简单的项目，因为它是基于WordPress构建的，很少有JavaScript在CSS中仍然可以非常复杂 - 好吧，你不需要做任何服务器端编码，所以这部分很简单，但是小册子磨损的前端每个都有二十个模块和三个变体：你有一些非常复杂的CSS！

Web组件

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

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

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

最后

我还认为这是一个优秀的，现代化的最佳实践css指南 - 专门用于阻止大型CSS项目变得混乱。我尝试跟随其中的大部分内容。

---

这里有一些很棒的材料，有些已经花了很多时间来回答这个问题，但是当涉及到单独或单独的样式表时，我会使用单独的文件进行开发，然后进入所有通用的css用于整个选址的合并部署时将其放入单个文件中。

通过这种方式，您可以充分利用这两个方面，提高性能(减少从浏览器请求的HTTP请求)以及在开发过程中分离代码问题。

---

我建议你看看"Compass Style"CSS框架。

---