我最近玩过CSS网格,包括像Susy(http://susy.oddbird.net/),Foundation(http://foundation.zurb.com/)和& amp;语义网格系统(http://semantic.gs/)。
他们都共享这个“包括”网格mixin的选项,而不是指定一个html类,例如。
.some-div{
@include grid-column(4);
}
虽然这看起来像是一个很好的语义方法,但我想知道css权重,css逻辑方面的成本,以及它是否真的值得它只是语义?
使用mixin grid vs html类有什么优缺点?
答案 0 :(得分:6)
网上有很多关于此的文章!只需谷歌,你会发现很多宝贵的信息。
这是一个很好的:How Important Is Semantic HTML?
语义html非常重要,因为它是:
清洁 - 更容易阅读和编辑,这样可以节省维护期间的时间和金钱,而且您不必强迫所有用户下载多个样式的文件库甚至没有在网站上使用
更易于访问 - 可以通过更多种类的设备更好地理解它。然后,这些设备可以根据设备的最佳设置添加自己的风格和演示。它也更适合JS框架。
搜索引擎友好 - 由于搜索引擎对内容进行排名而不是代码,这仍然存在争议,但搜索引擎正在更多地使用微格式等内容来理解内容。
< / LI>对我来说,最重要的论点是语义方法只是......正确的做法。仔细遵循这种方法,你就会有更少的遗憾。
谷歌的语义方法极端主义,并且违反了自己的style guide这么多次,这太荒谬了。只需查看Google搜索结果或HTML的HTML代码,您就会感到恶心。有必要了解谷歌是一个超高负荷的网站,他们交易一切有利于毫秒加载。
Mohamad的主要论点是大型项目的语义方法很难。事实上,这只适用于旧式CSS。
实际上,使用纯CSS的语义风格会产生反作用。项目越大,采用语义方法所需的工作就越多。
但是SASS。无论谁尝试过SASS,都不会回归到香草CSS。 SASS提供了许多强大的改进,其中一些使编码在语义上毫不费力。
SASS代码被编译成普通的CSS代码。了解SASS最重要的一点是,您只需关心SASS代码的结构和可读性。生成的CSS代码可能难以阅读并包含重复项,但这不是问题,因为CSS是由服务器进行gzip压缩。
关注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,.extenral-link { 显示:内联; 宽度:16px; 身高:16px; background-repeat:no-repeat; }
.star { background-image:url(“../ images / star.png”); }
.extenral-link { background-image:url(“../ images / external-link.png”); }
很遗憾,您无法在媒体查询中使用漂亮的@extend
功能。因此,如果您进行响应式设计,则必须生成包含重复片段的CSS代码。正如我之前所说,由于gzip,CSS中的重复不是问题,重要的是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
mixin。那是因为它来自令人敬畏的Singularity扩展。
众多Compass扩展的生态系统为您提供了一套适合所有需求的工具:语义网格系统,响应式设计,颜色,数学,各种风格......您无需重新发明数千个轮子你建立的每个项目!
这是SASS新人的一个很好的起点:https://github.com/Snugug/training-glossary/wiki,由Sam Richard aka Snugug创建。
答案 1 :(得分:2)
我经常觉得语义网格的一些拥护者从未编写过复杂的应用程序。答案一如既往,是众所周知的“依赖”。
这取决于您的风格,团队和应用程序。在一些需要模块化设计的项目中,语义需要额外的代码和努力才能获得非常小的回报。在其他人,更简单的,它很好。看一下Google使用的CSS。不是每个人都是谷歌大小,但这说明了我的“依赖”点。
HTML 5的出现解决了section
,header
和article
等标记的部分问题。我倾向于在语义上使用它们。但是我的CSS类名称倾向于描述我的设计的抽象划分,而不是 的具体内容。
没有直接的答案,但要注意不要浪费太多时间担心这些东西。如果你的申请迟到或没有出门,这意味着很少。
做你和你的团队感到满意的事。