什么是语义化：语义化Web具备让数据跨终端共享／重用的能力。
对于HTML体系而言，Web语义化是指使用语义恰当的标签，使页面有良好的结构，页面元素有含义，能够让人和机器都容易理解。
语义化说起来好像都懂，但是实际情况并不是那么乐观。
再谈各种所谓的CSS设计模式
OOCSS (Object Oriented CSS)
目标：
- 减少对HTML结构的依赖
- 增加CSS class重复性的使用
<div class="item">
<ul class="item-list">
<li class="item-list--item">
<h3 class="item-heading">...
<button class="button button-primary">primary</button>
<button class="button button-info">info</button>
SMACSS(Scalable and Modular Architecture for CSS)：一种css架构风格。
<div class=“container”>
<div class=“container-header”>
<div class=“container-header__title”>
<h1 class=“container-header__title--home”>
BEM(Block,Element,Modular)：与SMACSS类似。
<ul class="menu">
<li class="menu__item">...</li>
<li class="menu__item_state_current">...</li>
<li class="menu__item">...</li>
</ul>
METACSS | ATOMCSS (原子CSS)
<div class="fl mr10 red">
<span class="blue fl"></span>
</div>
为什么会有这么多层出不穷(千奇百怪)的CSS设计模式
1.CSS本身的不足，不具备逻辑表达能力 & 抽象能力
2.We had to maintain a shit。。。所以我们需要更有效的去减少让自己恶心的成本。。
但这些都只是部分客观原因，主要原因在于我们对于Web语义化的理解度不够以及非正确的工作流。
以表现为中心(面向UI) VS 以信息为中心(面向语义)
以表现为中心的工作流： 需求原型 --> UI设计稿 --> 以HTML／CSS实现设计稿
以信息为中心的工作流： 需求原型 --> 分析需求并以HTML描述 --> UI设计稿 --> 分析样式并以CSS实现
两者最大的区别在于，对于面向UI的工作流而言，HTML／CSS只是实现UI的手段，而对于纯正的Web开发(面向语义的工作流)而言，我们应该是以信息为中心的，即首先考虑信息的本质(语义)，并以合适的标签来标记，最后再考虑样式和行为(UI)。
之所以会有那么多层出不穷(不知所谓)的CSS设计模式，是因为它们大都是以表现为中心提出的“最佳实践”，而这两种方法论本身又是不适配的。
为什么说面向语义(以信息为中心)才是纯正的Web开发
1.Web诞生的目的是用于在网络上传递资源跟信息的。HTML设计之初是用来作为互联网上主要的内容载体，其本身是用来描述信息的。在最早期的Web时代，HTML作为一种通用的描述语言用来表述在互联网上传输／共享的文档的信息。
Web 万维网
HTML 作为一种对计算机而言通用易懂的母语
2.Web领域的一套基础架构跟技术（包括HTTP、REST、HTML等），是按照语义中心的方式设计出来的。如果采用UI中心的方法论，必然导致阻抗不匹配。
3.w3c官方也在致力于推广Web语义化
- 各种表现型标签／属性在HTML5中被废弃／不推荐使用(center、big、width等)
- HTML5中新增的各种语义化标签(header、nav等)，而这些标签在表现上跟div无二。
CSS语义化？
通常意义上我们说的CSS语义指的是class的语义。class作为HTML与CSS之间的主要钩子，却是被我们误解最深的一个东西。
class属性本意是用来描述元素内容的，而不是描述元素展现的。其典型‘反模式’代表就是METACSS。
看看这两段代码，哪一个更容易理解？
<!-- 以表现为中心 -->
<div class="fl mr10">
<span>userName:Kuitos</span>
<div>
<!-- 以信息为中心 -->
<div class="user-info">
<span>userName:Kuitos</span>
<div>
class作为HTML描述属性集的一部分，本身是用来细化内容语义的，所谓的CSS语义化本质上就是HTML语义化。
符合标准的最佳实践
在CSS领域发展的初期，严格意义上的“最佳实践”都是不存在的，这主要受制于CSS的支持度，大部分浏览器的CSS的支持不够好，所以也导致我们很难在表现及语义之间做平衡。所以我们在翻看HTML标签的时候会看到诸如<b><center>这类纯样式的历史性标签(这些标签已经不被HTML5 spec推荐使用)。
但是为什么到了CSS已经如此强大(且浏览器支持度也都挺好)的年代，依然会出现那么多实质还是以表现为中心提出的所谓“最佳实践”？其实，这归结起来，源于我们对于CSS复用的这种刚性需求。
以OOCSS为例，我们写一组按钮可能会这么写：
<button class="button-primary"></button>
<button class="button-error"></button>
.button-primary {
width: 80px;
height: 40px;
background-color: green;
...
}
.button-error {
width: 80px;
height: 40px;
background-color: red;
...
}
我不能每写一个button都重复一遍宽高啊，要复用，所以我们可能会把公共部分提取出来。
<button class="button button-primary"></button>
<button class="button button-error"></button>
.button {
width: 80px;
height: 40px;
}
如果你秉承这个思路，当哪天产品要求第一个按钮要左排第二个要右排的时候，我估摸着你会很自然的这么去写：
<button class="button button-primary float-left"></button>
<button class="button button-error float-right"></button>
.float-left {
float: left;
}
.float-right {
float: right;
}
更甚者，哪天产品要求第二个按钮跟右边隔10像素，你会不会这么写？
<button class="button button-error float-right mr10"></button>
css我就不写了mr10什么意思我猜你已经知道了。。
且不说<button class="button button-primary"></button>这种写法中button本身就是一种冗余信息(我当没看见也罢)，mr10则基本上无法忍受了，仔细想想这跟直接写inline-style有什么差别？相反我写inline-style更符合标准，至少我是挂载在专门用于描述表现的style属性上面，而不是用来描述内容的class上面。
基于这样的一连串演进，最后大概会诞生出两个症状：
1.样式类 即一系列诸如 mr10 fl之类的class
2.多class症 即几乎每个元素上都要挂载至少一个class。
原因在于，如果我们需要达到复用的效果，最后必定会魔障出一条理念：样式需具备独立性与上下文无关，同时粒度需要够小(样式类／通用原子类)。
其中也有一个主要原因是我们对CSS的误解。
css ＝ 层叠样式表，其关键词在层叠
“复用”需求最后一定会导致我们样式退化到平级的单class规则定义，因为这样才能足够无状态。但实际上CSS最独特的地方在于层叠，你避开这种机制从而来满足复用需求，最后不单单丧失了CSS的能力，反而会催生出一系列不符合语义化标准的反模式。
但是我也说过，复用是刚需，而CSS又不具备抽象能力，所以我们只能眼睁睁的看着一坨坨屎流行么？
好在我们有预处理器
最佳实践 Sass/Less
Sass/Less我这里就不一一赘述了，时至今日相比大家都很熟悉。为什么说最佳实践是Sass/Less呢？简单来说，就是这类预处理器在提供一定的抽象能力的同时，也不会破坏css自身的特性。拿上面的例子来看，如果我们使用Sass/Less的写法：
%button {
width:80px;
height:40px;
}
.button-primary {
@extend %button;
background-color: white;
}
.button-success {
@extend %button;
background-color: green;
}
.button-error {
@extend %button;
background-color: red;
}
如果我们在项目级别需要统一的配色，可以做进一步的抽象
$primary-bgc: white;
$success-bgc: green;
$error-bgc: red;
.button-primary {
@extend %button;
background-color: $primary-bgc;
}
.button-success {
@extend %button;
background-color: $success-bgc;
}
.button-error {
@extend %button;
background-color: $error-bgc;
}
同样的手段还有mixin。
我们可以将我们需要复用的“样式类”抽象成placeholder／mixin(对于“通用原子类”这样的需求我推荐用placeholder)，然后使用语义化的 class／属性 作为钩子，来组装这些“原子类”(但实际上这些“原子类”对CSS而言是不可见的)。比如我们用a标签来模拟一个提交按钮，我们应该这样写：
<a href＝"#" role="submit-button">提交</a>
a[role="submit-button"] {
@include .button-success;
}
所以css的最佳实践应该是： Sass + OOCSS/BEM/METACSS
这里有一个关键点在于，我们在使用这些css抽象方法论来写sass的时候，切记不要把中间变量暴露给css。什么意思呢，button那个例子我这样来写
.button{
width: 80px;
height: 40px;
}
.button-primary {
@extend .button;
}
此时button对于css而言是可见的。对于button这类抽象产物，我们应该用placeholder和mixin代替，确保其对css的不可见从而保证web的“纯度”。(这也是我不推荐Less的原因，Less最大的失误在于没有placeholder的设计)
到这里估计思考过的同学会有疑问：很多场景可能并没那么容易语义化，比如我要第一个元素左浮动，第二个元素右浮动，第三个又左浮动，第四个右浮动。。。
这里需要提到另一个经常被误解的点：selector。selector作为HTML与CSS的结合点，实质上也是需要语义化的。tag跟id是天生带语义的，主要问题还是出在class上。我们总是尝试在class上挂载一些表现型的“名称”。这里面有一小部分确实是由于CSS本身的不完美(比如layout这种场景细则就比较难语义)导致的，但是过多的则归咎于我们语义化动力不足及对selector的认知不够。语义化动力不足完全是主观因素这里不赘述，对selector认知不够则是最普遍存在的情况。推荐阅读：为后代选择器及id选择器辩护 结合智能选择器的语义化的CSS。
为什么一定要按标准来？
其实我不太想回答这种问题。。。我更想反问：为什么不按标准来？！！
一定要说的话：
推行标准的目的是为技术交流构建一个统一的上下文语境平台，提高沟通效率，避免鸡同鸭讲。
同时标准跟规范的制定是经过一群 资深开发者／科学家 经过仔细研究及社区讨论的，一套完整的一致的基础架构系统是推进生态发展的必要条件。
就Web语义化这件事情而言，如果你的HTML是基于标准来编写的，意味着你的页面具备更多的可能性。比如搜索引擎友好，多终端适配(不是响应式。。是指兼容各种阅读设备、读屏软件等。参见microformats)，更智能的风格查错能力。
在前端开发体系里，能体系专业性的地方不多。。拿程序复杂度而言，它跟大型后端系统差不止一个量级(前端的难度在于工程上)。。好不容易有一个能体现专业素养的领域(语义化Web)，为什么我们不抓住机会为自己正名呢。。
推荐阅读：
http://hax.iteye.com/blog/497338
http://hax.iteye.com/blog/500015
http://hax.iteye.com/blog/849826
