为什么不为Compass/Blueprint Grid使用语义类名？

Question

我最近开始了一个大型的多年客户端项目,前端开发的第一阶段是创建一个在整个项目中使用的模式库.我正在为我的网格使用Compass和Blueprint.该@include blueprint-grid混入看上去很适合这个项目:它会自动生成语义类名(即.span5),该团队的其他成员可以在所有页面中重用.

但是,Compass文档指出:

最佳做法不鼓励使用此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 来实现。

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

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