按元素、功能和媒体查询构建 CSS（SASS、LESS）文件：3D 代码结构？ [关闭]

Question

零维度

每个人都从一个包含所有样式的文件开始使用 CSS。

• style.css

1D

很快它就变得庞大了，人们决定按页面元素将 CSS 分组到多个文件中：

• html_elements.css
• header.css
• main-area.css
• footer.css

有些人可能觉得这不够方便，并按功能对样式进行分组：

• typography.css
• layout.css
• sticky-footer.css（包含许多元素的声明，而不仅仅是页脚）

二维

当一个项目有很多 CSS 时，它可能需要同时使用这两个分组。 CSS 文件结构变成二维的：

layout/

• grid-system.css
• header.css
• sidebars.css

look/

• typography/
  • main.css
  • headers.css
  • lists.css
• backgrounds/
  • html_elements.css
  • header.css
  • main-area.css
  • footer.css

好吧，这个例子是虚构的，但你确实明白我的意思。

到目前为止一切都很好。

输入媒体查询

这就是我的 CSS 结构被搞砸的地方。

除了上述的 2D 结构之外，我还必须通过媒体查询来构建我的代码：

• 我的一些样式是通用的（适用于任何地方）
• 有些仅适用于某些屏幕尺寸：
  • 小；
  • 中等;
  • 大；
  • 特大号。
• 有些适用于某些屏幕尺寸组：
  • 除小型（非移动样式）外的所有内容；
  • 小型和中型（侧边栏不在侧边）
  • large 和 xlarge（您确实有侧边栏）

我试图通过在现有 CSS 文件中分散媒体查询样式来解决这个问题。 breakpoint Compass 扩展有很大帮助，但是样式表变得太乱了。当文件结构中没有描绘出某种风格时，要找到一种风格会很痛苦。

我尝试按媒体查询分组，然后按元素和功能分组。但是文件结构是二维的，所以你不能添加新的维度，你只能添加另一个层次结构。所以，并不优雅。而且，它非常笨重。

所以我最终得到了一个 2D 结构，一个轴上有媒体查询，而另一个轴上有元素和功能的丑陋组合。

我对此绝对不满意，但我只是未能提出一个优雅的解决方案。请推荐一个。

Answer 1

为什么不尝试这样的事情：

/root
  /modules
    /header
      /html
        header.html
      /css
        module_styles.css /*Configure which style sheets are included with @media rule in this file*/
        /at-media
          small.css
          medium.css
          large.css
      /js
        fancy-nav.js
  /site
    includes.css /*use @import to include each modules stylesheet in a file here and let each module control its own media issues*/

Answer 2

我最终要做的是您的 2D 解决方案（尽管我的有更多嵌套）并在需要时使用 Breakpoint 将我的媒体查询写入行中。我们需要处理的一件事是我们的输出 CSS 看起来与我们的手写代码不同，它是使用 CSS 预处理器并专门抽象周围事物的现实。很快，Google Chrome's dev tools are going to come with built in Sass partial support，还有FireSass 让 Firefox 帮助您找出样式的来源。

希望这些帮助！

Answer 3

好吧，这更多是个人品味的问题，可能没有真正回答这个问题，但这是我的贡献：

我所做的是一个像你说的“2D”组织，文件少很多（假设我们说的是 css，预处理器更少）

我发现在我正在设置样式的元素的同一个“less”文件中使用媒体查询更容易。

例如，我有 header.less 并且在同一个文件中，它的媒体查询。

#header {
    ...
}

//Header media queries
-----------------------

@media screen and (min-width:480px) { ... }
@media screen and (min-width:768px) { ... }

现在，为什么我选择这样做？ -> 因为（对我来说）这是一个巨大的痛苦......必须查看另一个文件（例如 responsive.less），在其中搜索媒体查询的标题，进行我的更改......等等。相反，使用这种方法，我总是知道我的媒体查询在哪里，并且每个元素都可以轻松访问/修改它们，这不会在代码中添加更多行。

唯一的问题是，当生成 css 时，我们最终会得到对遍布 css 代码的单个元素的媒体查询。不是很漂亮！ （此时 less/winless 不会自动对媒体查询进行分组。）

我结束了构建一个小应用程序来对媒体查询进行分组：http://nokturnalapp.com/mqhelper/ 我用它来构建用于生产的 css 文件。 （还没有完成，我需要添加从媒体查询版本中剥离的代码，但看看它。）

我希望这对您有所帮助。

Answer 4

CSS 已经是一种结构化语言。无论好坏，代码的顺序都会改变它的含义。因此，任何 CSS 组织方案都主要由级联决定，这一点很重要。 CSS 的另一个结构方面是语义。使用它来发挥你的优势。组织关注的是保持事物的意义和可维护性。保留意义的最佳方法是展示关系。关系已经用语义表达了。

把这些东西放在一起，你最终会得到首先按specificity组织的代码，然后是semantics，但永远不会按外部概念，例如类型与布局或屏幕-尺寸。这是我的命名方案：

base/
  - Sass imports and settings - no CSS output.
  - e.g _grid, _colors, _rhythm, etc.
general/
  - Initial CSS baseline with resets, defaults, font imports, and classes to extend.
  - e.g. _reset, _root, _fonts, _icons, _defaults, etc.
layout/
  - The rough outline of the site structure.
  - Not "layout" as a set of properties excluding type, "layout" as the overall site template which might well include typography. 
  - e.g. _banner, _nav, _main, _contentinfo, etc.
modules/
  - All the details. First by effect (classes/general), then by widget (ids/specifics).
  - e.g. _users, _admin, _product-lists etc.

媒体查询应尽可能靠近它们影响的代码。如果可能，它们直接内联（使用 Sass 媒体冒泡）。如果它变得庞大，它们会移出块外，但永远不会移出部分。 MQ 是覆盖。覆盖代码时，能够准确地看到被覆盖的内容尤为重要。

在某些网站上，您可以更进一步地采用这种结构。我偶尔会在最后添加两个文件夹：plugins/ 用于管理第 3 方代码，overrides/ 用于处理不可避免的（尽量避免使用它们！）特定于位置的小部件覆盖。我也更深入了，为每个字体系列添加了一个带有部分的 fonts/ 文件夹，或者为添加、编辑、查看等添加了一个带有部分的 users/ 文件夹。细节是灵活的，但基本组织保持不变：

• 开始常规。
• 尽可能缓慢地处理细节。
• 切勿根据任何外部概念（类型/布局、屏幕尺寸等）进行划分。