CSS网格:语义的重要性

Question

我最近使用了CSS网格，包括苏西(http://susy.oddbird.net/)、基金会(http://foundation.zurb.com/)和语义网格系统(http://semantic.gs/)这样的优秀框架。

它们都共享“包括”网格混合输入的选项，而不是指定html类。

.some-div{
  @include grid-column(4);
}

虽然这似乎是一种很好的语义方法，但我想知道css权重、css逻辑的代价，以及它是否真的值得仅仅是语义？

使用混合网格与html类的优缺点是什么？

Answer 1

为什么HTML/CSS语义很重要

网上有很多关于这方面的文章！只要在谷歌上搜索，你就会发现很多宝贵的信息。

这里有一个很好的例子：语义HTML有多重要？

语义html很重要，因为它是：

• Clean --它更容易阅读和编辑，这在维护过程中节省了时间和金钱，而且您不必强迫所有用户下载一个臃肿的样式库，其中许多样式甚至没有在网站上使用
• 更容易访问--更多的设备可以更好地理解它。然后，这些设备可以根据对设备最好的内容添加它们自己的样式和表示。它也更适合于JS框架。
• 搜索引擎友好的-这仍然是有争议的，因为搜索引擎排名内容而不是代码，但搜索引擎正在更多地利用诸如微格式来理解内容。

对我来说最重要的论点是语义方法只是..。做正确的事。仔细遵循这个方法，你就不会有太多后悔的理由了。

为什么我不同意@Mohamad的回答

谷歌是个坏例子。

谷歌的语义学方法是极端的，并违反了他们自己的风格指南太多次，这是荒谬的。只要看看Google搜索结果或HTML的HTML代码，你就会感到恶心。有必要明白，谷歌是一个超高负荷的网站，他们交换一切，以毫秒为加载。

使用SASS使用CSS很笨重。

Mohamad的主要论点是，语义方法在大型项目中是困难的。事实上，这只适用于旧式的CSS。

实际上，使用纯CSS的语义风格是适得其反的。项目越大，就需要更多的精力去采用语义方法。

但是有沙斯。无论谁尝试过SASS，都不会再回到普通的CSS中。SASS提供了令人难以置信的许多强大的改进，其中一些使编码在语义上毫不费力。

SASS代码被编译成普通的CSS代码。了解SASS最重要的一点是，您只需关心SASS代码的结构和可读性。生成的CSS代码可能很难阅读并包含重复的内容，但这并不是一个问题，因为CSS是由服务器进行gzipped的。

@扩展

与HTML/CSS语义相关的最重要的SASS特性是@extend指令。它允许您将可重用的样式块注入语义选择器，同时生成高效的CSS。

首先，声明要重用的样式块，例如：

%glyph {
  display: inline;
  width: 16px;
  height: 16px;
  background-repeat: no-repeat; }

以后，您可以在语义上将它包含到不同的选择器中：

.star {
  @extend %glyph;
  background-image: url('../images/star.png'); }

.extenral-link {
  @extend %glyph;
  background-image: url('../images/external-link.png'); }

由此产生的CSS将非常有效：

扩展链接{ .star :内联；宽度:16 no；高度:16 no；背景-重复:不重复；}

.star {背景图像:url(“./image/star.png”)；}

.扩展名-链接{背景-图像:url(“../图像/外部链接.url”)；}

@include

不幸的是，您不能在媒体查询中使用漂亮的@extend功能。因此，如果您进行响应性设计，则必须生成带有重复片段的CSS代码。正如我前面说过的，CSS中的复制不是一个问题，这要归功于gzip，重要的是SASS的清洁。

Mixins (@include)允许您将可重用样式块注入选择器。它们不能有效地分组，但它们接受参数，并且可以为不同的语义选择器生成不同的样式：

@import 'singularitygs';

$breakpoint: 300px;

$grids: 2 3;
$grids: add-grid(6 at $breakpoint);

%column {
  background-color: pink;
  min-height: 5em;
  margin-bottom: 1em;}

#welcome {
  @extend %column;
  @include grid-span(1, 1);

  @include breakpoint($breakpoint) {
    @include grid-span(2,1); }}

#product-features {
  @extend %column;
  @include grid-span(1, 2); 

  @include breakpoint($breakpoint) {
    @include grid-span(2,3); }}

#description {
  @extend %column;
  clear: both;  

  @include breakpoint($breakpoint) {
    @include grid-span(2,5); }}

生产：

#welcome, #product-features, #description {
  background-color: pink;
  min-height: 5em;
  margin-bottom: 1em;
}

#welcome {
  width: 38.09524%;
  float: left;
  margin-right: -100%;
  margin-left: 0%;
  clear: none;
}
@media (min-width: 300px) {
  #welcome {
    width: 31.03448%;
    float: left;
    margin-right: -100%;
    margin-left: 0%;
    clear: none;
  }
}

#product-features {
  width: 57.14286%;
  float: right;
  margin-left: 0;
  margin-right: 0;
  clear: none;
}
@media (min-width: 300px) {
  #product-features {
    width: 31.03448%;
    float: left;
    margin-right: -100%;
    margin-left: 34.48276%;
    clear: none;
  }
}

#description {
  clear: both;
}
@media (min-width: 300px) {
  #description {
    width: 31.03448%;
    float: right;
    margin-left: 0;
    margin-right: 0;
    clear: none;
  }
}

演示：http://sassbin.com/gist/5883243/

罗盘扩展

正如您在上面注意到的，我使用了代码中没有声明的grid-span混音。那是因为它来自于超棒的奇点扩展。

众多罗盘扩展的生态系统为您提供了一套满足所有需求的工具:语义网格系统、响应性设计、颜色、数学、各种样式.你不必为你构建的每一个项目重新发明上千个轮子！

关于SASS的读物是什么

对于SASS新手来说，这是一个很好的起点：https://github.com/Snugug/training-glossary/wiki，由萨姆·理查德·卡·斯努格创建。

Answer 2

我经常觉得一些语义网格的拥护者从来没有写过复杂的应用程序。与以往一样，答案是众所周知的“依赖”。

这取决于你的风格，你的团队和你的应用程序。在一些需要模块化设计的项目中，语义化需要额外的代码和努力才能获得很少的回报。在另一些，简单的，它是好的。看看Google使用的CSS。并不是每个人都是谷歌大小的，但这说明了我的“依赖”点。

HTML5的出现解决了一些使用section、header和article等标记的问题。我倾向于在语义上使用这些。但是我的CSS类名倾向于描述我的设计中抽象的部分，而不是具体的内容。

没有直截了当的答案，但要小心不要浪费太多时间来担心这些事情。如果你的申请迟到了，或者没有赶出去，那就没什么意义了。

做你和你的团队觉得舒服的事情。