我可以建议少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;
}

以下是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.

合理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.

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

类似的

/* Headings and General Text */

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

/* Main page layout */

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

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

不要用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文件到单个文件中。但是，由于这些文件是分开的，对它们的测试也是分开的，因此可能会在页面/部分之间引入不一致的外观。因此测试变得更加困难。

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