Web语义化标准解读

kuitos commented 8 years ago

15年年末写了篇关于BEM方法论(实践上内容并不是原BEM)的文章，文末给自己挖了个坑说要聊聊Web语义化，跳票至今😂。16年第一篇用来填坑好了！

什么是语义化

The Semantic Web provides a common framework that allows data to be shared and reused across application, enterprise, and community boundaries. --Wikipedia

语义化Web具备让数据跨终端共享／重用的能力。

对于HTML体系而言，Web语义化是指使用语义恰当的标签，使页面有良好的结构，页面元素有含义，能够让人和机器都容易理解。

语义化说起来好像都懂，但是实际情况并不是那么乐观。

再谈各种所谓的CSS设计模式

OOCSS (Object Oriented CSS)

...a CSS “object” is a repeating visual pattern, that can be abstracted into an independent snippet of HTML, CSS, and possibly JavaScript. That object can then be reused throughout a site. — Nicole Sullivan
```
<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>
```
目标：
- 减少对HTML结构的依赖
- 增加CSS class重复性的使用

SMACSS(Scalable and Modular Architecture for CSS)

...an attempt to document a consistent approach to site development when using CSS. — SMACSS

<div class=“container”>
  <div class=“container-header”>
      <div class=“container-header__title”>
          <h1 class=“container-header__title--home”>

一种css架构风格

BEM(Block,Element,Modular)

The BEM approach ensures that everyone participating in the development of a website is working with the same codebase and using the same terminology — BEM Methodology
```
<ul class="menu">
  <li class="menu__item">...</li>
  <li class="menu__item_state_current">...</li>
  <li class="menu__item">...</li>
</ul>   
```
与SMACSS类似

METACSS | ATOMCSS (原子CSS)

<div class="fl mr10 red">
  <span class="blue fl"></span>   
</div>

WTFSS
为什么会有这么多层出不穷(千奇百怪)的CSS设计模式

Cascading Style Sheets (CSS) are a stylesheet language used to describe the presentation of a document written in HTML or XML (including XML dialects like SVG or XHTML). CSS describes how elements should be rendered on screen, on paper, in speech, or on other media. －－MDN

CSS本身的不足，不具备逻辑表达能力 & 抽象能力

We had to maintain a shit。。。所以我们需要更有效的去减少让自己恶心的成本。。

但这些都只是部分客观原因，主要原因在于我们对于Web语义化的理解度不够以及非正确的工作流。

以表现为中心(面向UI) VS 以信息为中心(面向语义)

以表现为中心的工作流：需求原型 --> UI设计稿 --> 以HTML／CSS实现设计稿

以信息为中心的工作流：需求原型 --> 分析需求并以HTML描述 --> UI设计稿 --> 分析样式并以CSS实现

两者最大的区别在于，对于面向UI的工作流而言，HTML／CSS只是实现UI的手段，而对于纯正的Web开发(面向语义的工作流)而言，我们应该是以信息为中心的，即首先考虑信息的本质(语义)，并以合适的标签来标记，最后再考虑样式和行为(UI)。

之所以会有那么多层出不穷(不知所谓)的CSS设计模式，是因为它们大都是以表现为中心提出的“最佳实践”，而这两种方法论本身又是不适配的。

为什么说面向语义(以信息为中心)才是纯正的Web开发

Web诞生的目的是用于在网络上传递资源跟信息的。HTML设计之初是用来作为互联网上主要的内容载体，其本身是用来描述信息的。在最早期的Web时代，HTML作为一种通用的描述语言用来表述在互联网上传输／共享的文档的信息。
Web 万维网

The World Wide Web (WWW) is an open source information space where documents and other web resources are identified by URLs, interlinked by hypertext links, and can be accessed via the Internet.

HTML 作为一种对计算机而言通用易懂的母语

To publish information for global distribution, one needs a universally understood language, a kind of publishing mother tongue that all computers may potentially understand.
Web领域的一套基础架构跟技术（包括HTTP、REST、HTML等），是按照语义中心的方式设计出来的。如果采用UI中心的方法论，必然导致阻抗不匹配。
w3c官方也在致力于推广Web语义化
- 各种表现型标签／属性在HTML5中被废弃／不推荐使用(center、big、width等)
- HTML5中新增的各种语义化标签(header、nav等)，而这些标签在表现上跟div无二。
  CSS语义化？

通常意义上我们说的CSS语义指的是class的语义。class作为HTML与CSS之间的主要钩子，却是被我们误解最深的一个东西。

There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content. --w3c

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上面。

基于这样的一连串演进，最后大概会诞生出两个症状：

样式类即一系列诸如 mr10 fl之类的class
多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)，为什么我们不抓住机会为自己正名呢。。

推荐阅读：

rockcoder23 commented 8 years ago

//button.sass

%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;
}

赞博主思考，根据文章意思是只对外暴露.button-primary, .button-success, .button-error这几个class，不知道我理解对不对？

还有我想知道这种最佳实践下怎么应对哪天产品要求第一个按钮要左排第二个要右排的时候这样的需求，这个最佳实践貌似并没有解决。

kuitos commented 8 years ago

@rockcoder23 对于这类需求，其实文中有透露一些信息。假设你的代码是这样的

<div class=""btn-group>
  <button class="button-primary">primary</button>
  <button class="button-errro">error</button>
</div>

第一个左移第二个右移，这样写不就好了

.btn-group {
    .button-primary {
        float:left;
     }

    .button-error {
        float:right;
    }
}

css的核心能力就是层叠啊。

rockcoder23 commented 8 years ago

@kuitos 了解了~ 谢谢博主~

limichange commented 8 years ago

我觉得，css全局性导致了我们得做这样的事。有了css作用域约束，我们就不用这么麻烦了。

leozdgao commented 8 years ago

我的理解是这样，首先比较赞同利用 Sass 以达到代码复用的目的。另外上面的例子里的 button.scss 应属于页面的组件层样式，这边没有问题，但是面临页面逻辑层的需求：

哪天产品要求第一个按钮要左排第二个要右排的时候

两种方式：

可以利用 CSS 层叠及选择器权值来设置样式（可能会提高维护成本）
添加描述表现的类（违背语义）

自己更倾向于面向语义的方式，感觉如果 CSS 分层清晰，命名科学（BEM等）的话，感觉 scoped 方案，比如 CSS Modules 可能不是很有必要，感觉更多是出于组件内聚的考虑，但它生成的 class 并不满足语义。

不过个人开发还好，如果是团队开发的话，可能很难保证面向语义，感觉不是自己能控制的。

恩，随便胡扯了几句 :smiling_imp: ，然后想问下：

OOCSS 减少对HTML结构的依赖

我怎么感觉它反而增加了对 HTML 结构的依赖呢？ :cry:

kuitos commented 8 years ago

@limichange 全局性只是一方面吧，我认为主要是不具备天生的抽象能力以及我们对语义化执行的力度不够，导致面对复用这种需求时会在岔路上越走越远。

kuitos commented 8 years ago

@leozdgao 是的，如果做的够好，CSS Modules的存在感会小很多。这里借机补充下，在真正实践中，我觉得应该这样操作：

组件层&抽象层，采取sass ＋ OOCSS／BEM 结合的方式写一些可复用的单元，这些单元是纯粹的内聚需要，对css而言不可见。

逻辑层利用语义化selector(包括class钩子，属性及高级选择器等语义化手段)，组合那些使用sass编写的可复用单元。

我觉得这并不会增加维护成本，反而会在长期内减少冗余样式、不可预知的样式覆盖等维护问题。唯一的成本可能就是你在开始一个页面之前，需要去抽象一下可复用的单元，然后用sass表达出来。不过我感觉如果你采用的是正确的工作流(面向语义)，这些事情都是比较顺理成章的。

对于团队开发如何确保面向语义，这确实是一个比较难解决的问题。除了需要提供一个清晰的团队sass库说明之外，貌似只能通过一些工程化手段解决了(加强code review流程、制定规范等等)。

limichange commented 8 years ago

@kuitos 嗯，认同。

ruohuan commented 8 years ago

LZ，有问题请教下

在某xxx.less文件中：

.btn() {
  display: inline-block;
  background-image: none;
  font-size: 12px;
  text-align: center;
  vertical-align: middle;
  white-space: nowrap;
  border-radius: 4px;
  border: 1px solid transparent;
  cursor: pointer;
  touch-action: manipulation;
}

.btn-default() {
  padding: 7px 20px;
}

.btn-primary() {
  background-color: #00a0ff;
  color: #fff;

  &:hover {
    background-color: #66c6ff;
  }

  &:focus, &:active {
    background-color: #0090e6;
  }
}

.btn-default-primary {
  .btn();
  .btn-default();
  .btn-primary();
}

调用btn-default-primary样式，btn、btn-default、btn-primary样式也没暴露出来，也就是说less也有这种placeholder的功能啊。

此外，采用这种写法，多种按钮样式之前就会产生冗余吧，这种情况和LZ在文中提到的该如何权衡呢？

kuitos commented 8 years ago

@ruohuan less的这个是mixin,mixin是include样式而不是placeholder那种合并的方式。你对比一下就知道了。对于button这种不需要传入变量的抽象单元，我觉得minix的方式不合适。而可惜的是less没有placeholder这种设计。

如果是合并而不是简单的include，自然也不会产生冗余的问题。

ruohuan commented 8 years ago

@kuitos 了解了，谢LZ

Justineo commented 8 years ago

《贺老博文和知乎回答之汇总详解》，哈哈。

kuitos commented 8 years ago

@Justineo nonono，不仅如此，准确来说是《贺老&10博文和知乎回答之汇总详解》 😂

watonyweng commented 8 years ago

感谢@kuitos对Web语义化的解读

clytiee commented 8 years ago

这篇文章真是好，昨天看过之后又补充了一些相关的知识，再回来看一遍，估计还要再看几遍才能理解&应用。谢谢！

Suscc commented 7 years ago

组件层&抽象层，采取sass ＋ OOCSS／BEM 结合的方式写一些可复用的单元，这些单元是纯粹的内聚需要，对css而言不可见。

@kuitos

文章真的好但还有一些疑问上述提到的 placeholder、mixin 之类的该如何命名呢如果要保证绝对的通用那么名称势必得特别的抽象题例您定义了一个名为 button 的类那么名称决定了这个类的实例只能是按钮啊限制了复用啊~

kuitos / kuitos.github.io