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”是一个语义名称，因为它根本不描述内容，而是以相当具体的方式描述布局。

_{当然，术语“语义”被抛出很多，但从最纯粹的意义上讲，它应该与演示文稿很少或没有任何关系。}

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

如果布局发生变化，则名称错误
布局可以适用于错误和/或无意义的不同设备。
标记对阅读它的人（即你的团队）意义不大
布局会变脆;改变一个在许多不同地方使用并具有许多不同含义的类可能会在某些使用它的地方中断。

像“span6”这样的泛型类的最大缺点是它们被滥用（我已经看过Bootstrap，它有类似的网格类定义）。 “我需要这个元素跨越2列......太棒了！我只需要打一个'span2'类就可以了！”

这并不意味着你不应该寻求重用;但重用可以来自与内容相关的类名（不可否认，这可能需要一些努力）和使用mixin。

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

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

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

1 个答案: