就像我之前说的:进入OOCSS。Sass/Less/Compass使用起来很诱人，但在正确使用CSS之前，Sass/Less/Compass只会让事情变得更糟。

首先，阅读高效css。尝试谷歌页面速度和阅读Souders关于高效css的文章。

然后进入OOCSS。

学会使用级联。(毕竟，我们称之为级联样式表)。 学习如何获得正确的粒度(自底向上而不是自顶向下) 学习如何分离结构和皮肤(什么是唯一的，这些对象的变化是什么?) 学习如何分离容器和内容。 学会爱上网格。

它将彻底改变css的每一个细节。我完全焕然一新，爱上了它。

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

我发现最难的事情是将网站所需的设计转化为一系列规则。如果站点的设计清晰且基于规则，那么你的类名和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原则。

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

一些意识形态与上面的答案相悖，但一旦你知道如何以面向对象的方式构建CSS，你就会发现它实际上有助于保持代码的精简和平均。

这里的关键是在你的网站中识别“对象”或构建块模式，并使用它们进行架构。

Facebook聘请了OOCSS的创建者Nicole Sullivan，以节省大量的前端代码(HTML / CSS)。是的，你实际上可以得到节省，不仅在你的CSS，但在你的HTML太，这是由它的声音，是非常有可能为你，因为你提到转换一个基于表格的布局到很多div的

另一个很好的方法在某些方面与OOCSS类似，就是从一开始就计划和编写可伸缩和模块化的CSS。Jonathan Snook写了一本关于SMACSS的书/电子书——CSS的可伸缩和模块化架构

让我给你介绍一些链接: 海量CSS的5个错误-(视频) 海量CSS的5个错误(幻灯片) CSS膨胀-(幻灯片)

我可以建议少CSS动态框架吗

它类似于前面提到的SASS。

它帮助维护每个父类的CSS。

E.g.

 #parent{     
  width: 100%;

    #child1
    {    
     background: #E1E8F2;    
     padding: 5px;    
    }

    #child2
   {
     background: #F1F8E2;
     padding: 15px
   }
 }

它的作用: 将width:100%应用于#child1和#child2。

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

这将导致

#parent #child1
{
 width: 100%;
 background: #E1E8F2;
 padding: 5px;
}

#parent #child2
{
 width: 100%;
 background: #F1F8E2;
 padding: 15px;
}

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

我注意到您只使用了类标识符(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

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.