我一直严重依赖CSS的一个网站，我正在工作。现在，所有的CSS样式都是在每个标签的基础上应用的，所以现在我试图将它移动到更多的外部样式，以帮助任何未来的变化。
但现在的问题是，我已经注意到我得到了一个“CSS爆炸”。我很难决定如何在CSS文件中最好地组织和抽象数据。
我在网站中使用了大量的div标签，从一个基于表格的网站。我得到了很多这样的CSS选择器:
div.title {
background-color: blue;
color: white;
text-align: center;
}
div.footer {
/* Styles Here */
}
div.body {
/* Styles Here */
}
/* And many more */
这还不算太糟，但由于我是初学者，我想知道是否可以就如何最好地组织CSS文件的各个部分提出建议。我不想在我的网站上的每个元素都有一个单独的CSS属性，我总是希望CSS文件是相当直观和易于阅读的。
我的最终目标是使它易于使用CSS文件，并证明他们的力量，以提高web开发的速度。这样，将来可能在这个网站上工作的其他人也将开始使用良好的编码实践，而不必像我一样学习。
合理CSS的核心原则，摘自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.
我的回答是高水平的，针对你刚才提到的高水平的关切。也许你可以通过一些低级的组织技巧和调整来使它更漂亮，但这些都不能解决方法上的缺陷。有几个因素会影响CSS的爆炸。显然是网站的整体复杂性，但还有像命名语义、CSS性能、CSS文件组织和可测试性/可接受性等问题。
在命名语义方面，您似乎走在了正确的道路上，但还可以更进一步。重复出现在站点上而没有进行结构修改的HTML部分(称为“模块”)可以被视为选择器根，从那里您可以相对于根确定内部布局的范围。这是面向对象的CSS的基本原则，您可以在Yahoo工程师的演讲中阅读/观看更多关于它的内容。
需要注意的是，这种干净的方法可能与性能问题相反，它倾向于基于id或标记名的短选择器。找到平衡取决于你，但除非你有一个庞大的网站，这应该只是一个指南在你的脑后提醒你保持你的选择器简短。这里有更多关于性能的信息。
最后，您将为整个网站使用一个CSS文件，还是多个文件(单个基本文件用于每个页面或-section文件)?单个文件对于性能来说更好，但是对于多个团队成员来说可能更难理解/维护，并且可能更难测试。对于测试，我建议您使用一个CSS测试页面，其中包含所有受支持的CSS模块，以测试冲突和意外级联。
或者，您也可以采用多文件方法，将CSS规则作用于一个页面或一个部分。这需要浏览器下载多个文件，这是一个性能问题。您可以使用服务器端编程动态地指定和聚合(并缩小)CSS文件到单个文件中。但是，由于这些文件是分开的，对它们的测试也是分开的，因此可能会在页面/部分之间引入不一致的外观。因此测试变得更加困难。
由你来分析客户的具体需求，并相应地平衡这些问题。
以下是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.
您还应该了解级联、权重以及它们是如何工作的。
我注意到您只使用了类标识符(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"的元素冲突。不要增加不必要的重量，因为你以后可能会用到这些重量。
