css - 按元素、功能和媒体查询构建 CSS(SASS、LESS)文件 : 3D code structure?

Question

很难说出这里问的是什么。这个问题模棱两可、含糊不清、不完整、过于宽泛或言辞激烈，无法以目前的形式合理回答。如需帮助澄清此问题以便可以重新打开，visit the help center .




8年前关闭。




零维

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

style.css

一维

很快它变得庞大，人们决定按页面元素将 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指南针扩展有很大帮助，但样式表变得太乱了。当文件结构中没有描绘出某种风格时，寻找某种风格会很痛苦。

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

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

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

Answer 1

CSS 已经是一种结构化语言。无论好坏，代码的顺序都会改变它的含义。因此，重要的是任何 CSS 组织方案都主要由级联决定。 CSS 的另一个结构方面是语义。充分利用它。组织关心的是让事情变得有意义和可维护。你能做的最好的事情就是展示关系。关系已经由语义表达了。

把这些东西放在一起，你最终会得到由 组织的代码。特异性先然后语义 ，但绝不会受到外部概念的影响，例如类型与布局或屏幕大小。这是我的命名方案:

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/文件夹，其中包含用于添加、编辑、查看等的部分。细节很灵活，但基本组织保持不变:

开始一般。

尽可能缓慢地转向具体细节。

从不 根据任何外部概念(类型/布局、屏幕尺寸等)进行划分。