为什么不对 Compass/Blueprint Grid 使用语义类名称？ [关闭]

Question

我最近开始了一个大型的多年客户项目，前端开发的第一阶段是创建一个模式库以在整个项目中使用。我正在为我的网格使用 Compass 和 Blueprint。 @include blueprint-grid mixin 看起来非常适合这个项目：它会自动生成语义类名（即.span5），团队其他成员可以在所有页面中重复使用。

但是，Compass documentation states:

最佳实践不鼓励使用此 mixin，但提供它是为了支持旧网站并针对蓝图的示例页面测试 sass 端口。

这是为什么呢？为什么要在现代网格系统中使用非语义类？为所有共享相同网格宽度的各种页面元素创建一个新的 CSS 类似乎不太干。例如：

.dashboard__chart {
    @include column(6);
}

.dashboard__news {
    @include column(6);
}

当我可以简单地将.span6 类应用于我的标记时。

这可能是情境性的：如果您的整个项目具有类似的布局（例如，新闻网站或博客），则非语义类是有意义的。但是，此仪表板/报告工具项目的每个页面的布局都有些不同。

回到最初的问题：为什么不使用语义类是最佳实践，以及避免它们的最佳方法是什么？

Answer 1

它会自动生成语义类名（即 .span5）

我不认为“span5”是一个语义名称，因为它根本不描述内容，而是以相当具体的方式描述布局。

_{当然，“语义”一词被广泛使用，但从最纯粹的意义上说，它应该与表示几乎没有关系。}

不使用描述演示的名称的原因：

1. 如果布局发生变化，则名称错误
2. 布局可能会针对不同的设备进行调整，但对于它来说是错误的和/或没有意义的。
3. 标记对阅读它的任何人（即您的团队）来说意义不大
4. 布局可能会变得脆弱；更改已在许多不同地方使用并具有多种不同含义的类可能会在某些使用它的地方中断。

像“span6”这样的泛型类的最大缺点是它们被滥用（我在 Bootstrap 中看到了这一点，它定义了类似的网格类）。 “我需要这个元素跨越 2 列......太好了！我只需在其上添加一个 'span2' 类就可以了！”

这并不意味着您不应该寻求重用；但是这种重用可以来自与内容相关的类名（诚然，这可能需要一些努力）以及通过使用 mixins。

我最近开始了一个大型的多年客户项目，并且 前端开发的第一阶段是创建一个模式库 在整个项目中使用。

为了实用性，大多数项目最终都会出现例外/妥协，但您有机会从最佳实践方法开始。