这个问题是关于在.css文件中组织实际的CSS指令本身。在开发一个新页面或者一组页面时，通常只将手工指令添加到.css文件中，尝试在可能的时候进行重构。一段时间后，我有数百(或者数千)行，调整布局时很难找到所需的内容。

有人对如何组织指令有建议吗？

• 我是否应该尝试自上而下地模仿DOM？
• 我是否应该在功能上进行组织，将支持UI相同部分的元素的指令放在一起？
• 我应该按选择器按字母顺序对所有内容排序吗？
• 这些方法的某种组合？

另外，在将一个文件拆分成多个单独的文件之前，我应该在一个文件中保留多少CSS是否有限制？说1000行吗？还是将整个事情放在一个地方总是一个好主意？

相关问题：组织CSS规则的最佳方法是什么？

解决方案

我尝试了许多不同的策略，但我总是回到这种风格：

.class {border: 1px solid #000; padding: 0; margin: 0;}

当涉及大量声明时，这是最友好的。

斯努克先生差不多在四年前就写过这句话：)。

但是，我们发现它最容易阅读！

认真地说，我们会得到十亿个建议和五个建议，但是我们只会喜欢几种方法。

我有些话要说：

• 将CSS文件分解成块确实可以将其组织起来，但这意味着来自浏览器的更多请求，最终导致服务器运行速度降低(更多请求)，并且浏览器需要更长的时间才能显示页面。记住这一点。
• 仅仅因为行数任意就分解文件是很愚蠢的(除了编辑器很糟糕-在这种情况下，请换一个新文件)

我个人是这样编写我的CSS的：

* { /* css */ }
body { /* css */ }
#wrapper { /* css */ }
#innerwrapper { /* css */ }

#content { /* css */ }
#content div { /* css */ }
#content span { /* css */ }
#content etc { /* css */ }

#header { /* css */ }
#header etc { /* css */ }

#footer { /* css */ }
#footer etc { /* css */ }

.class1 { /* css */ }
.class2 { /* css */ }
.class3 { /* css */ }
.classn { /* css */ }

将规则保持在一行上可以使我非常快速地浏览文件，并查看其中有哪些规则。当它们扩展时，我发现它太像努力工作，试图找出正在应用的规则。

由于实际排序是CSS应用方式的重要组成部分，因此继续"字母顺序"建议似乎有些愚蠢。

通常，我们希望将项目按它们影响的页面区域进行分组。例如。影响一切的主要样式，然后是页眉和页脚样式，然后是导航样式，然后是主要内容样式，然后是次要内容样式。

此时，我将避免分成多个文件，因为它可能更难以维护。 (当我们打开六个CSS文件时，很难在头脑中保持级联顺序)。但是，如果将样式仅应用于页面的子集，例如，我肯定会开始将样式移动到不同的文件。表单样式仅在页面实际包含表单时才链接到该页面。

排除常见样式。并非恰好是相同的样式，而是旨在相同的样式，其中更改一个选择器的样式可能意味着我们也要更改另一个选择器。我在另一篇文章中介绍了这种风格的示例：
在CSS文件中创建一个变量，以在该CSS文件中使用。

除此之外，将相关规则组合在一起。并将规则分成多个文件...除非每个页面实际上都需要每个规则。

我接受这个命令：

• 通用样式规则，通常适用于裸元素(a，ul，ol等)，但它们也可以是通用类(.button，.error)
• 适用于大多数/所有页面的页面布局规则
• 个别页面布局规则

对于适用于单个页面或者小的分组页面的任何样式规则，我将其主体设置为id和一个类，从而可以轻松地定位特定页面。 id是文件的基本名称，而class是文件所在的目录名称。

我倾向于这样整理我的CSS：

• reset.css
• 标头
• 导航
• 内容
• 页脚
• Additional- [页面名称] .css：仅在一页中使用的类

CSS文件缓存在客户端上。因此，将所有样式保存在一个文件中是一个好习惯。但是在开发时，我发现根据域来构造CSS很有用。

例如：reset.css，design.css，text.css等。当我发布最终产品时，我将所有样式都融合到一个文件中。

另一个有用的技巧是将可读性集中在规则上，而不是样式上。

尽管：

ul li
{
    margin-left: 10px;
    padding: 0;
}

看起来不错，当我们拥有100行代码时，要找到规则并不容易。

相反，我使用这种格式：

rule { property: value; property: value; }

rule { property: value; property: value; }

这是我的工作。我有一个CSS索引页，上面没有任何指令，它会调用不同的文件。这是一个简短的示例：

@import url("stylesheet-name/complete-reset.css");
@import url("stylesheet-name/colors.css");
@import url("stylesheet-name/structure.css");
@import url("stylesheet-name/html-tags.css");
@import url("stylesheet-name/menu-items.css");
@import url("stylesheet-name/portfolio.css");
@import url("stylesheet-name/error-messages.css");

它从完全重置开始。下一个文件定义了调色板以便于参考。然后，我对主要的<div />进行样式设置，以确定布局，页眉，页脚，列数，它们适合的位置，等等。 ，<p />，t等...接下来是站点的特定部分。

这是非常标量，非常清楚。查找要更改的代码并添加到dd新节要友好得多。

看一下以下三个幻灯片共享演示文稿：

• 漂亮的可维护CSS
• 可维护的CSS
• 高效，可维护的模块化CSS

首先，也是最重要的是，记录CSS。无论我们使用什么方法来组织CSS，都必须保持一致并记录下来。在每个文件的顶部描述该文件中的内容，也许提供一个目录，也许引用易于搜索的唯一标签，以便我们在编辑器中轻松跳转至这些部分。

如果我们想将CSS拆分为多个文件，则一定要这样做。 Oli已经提到额外的HTTP请求可能很昂贵，但是我们可以兼得两者。使用某种类型的构建脚本将文档充分的模块化CSS发布到压缩的单个CSS文件中。 YUI Compressor可以帮助压缩。

与到目前为止其他人所说的相反，我更喜欢将每个属性写在单独的行上，并使用缩进对相关规则进行分组。例如。以下是奥利(Oli)的例子：

#content {
    /* css */
}
    #content div {
        /* css */
    }
    #content span {
        /* css */
    }
    #content etc {
        /* css */
    }

#header {
    /* css */
}
    #header etc {
        /* css */
    }

这使得跟踪文件结构变得容易，尤其是在组之间留有足够的空格和清晰标记的注释时(尽管不那么容易快速浏览)并且易于编辑(因为我们不必在CSS的每一行中都要花很多时间每个规则)。

了解并使用级联和特异性(因此，按字母顺序对选择器进行排序是正确的)。

是否将CSS拆分为多个文件，以及将文件拆分为哪些文件，取决于站点和CSS的大小和复杂性。我总是至少有一个" reset.css"。对于一般的页面布局，通常会带有layout.css，如果站点导航菜单有点复杂，则带有nav.css，如果我有很多CSS来设置表单样式，则带有forms.css。除此之外，我还是自己弄清楚它。我可能要用colors.css和type.css / fonts.css来拆分颜色/图形和版式，base.css`要为所有HTML标签提供完整的基本样式...

我曾经不停地担心这一点，但是Firebug救了出来。

如今，查看样式如何通过Firebug相互关联并从中找出需要做的事情要容易得多。

当然，一定要确保有一个合理的结构将相关样式组合在一起，但不要太过分。 Firebug使事情变得更容易跟踪，我们不必担心要预先构建完美的CSS结构。