天这篇是我们正式开篇的第一篇文章，我想和你聊聊 HTML。

我猜屏幕那一边的你估计会说：“HTML 我很熟悉了，每天写，这不是初级程序员才学的内容

么，这我还能不会吗？”

其实在我看来，HTML 并不简单，它是典型的“入门容易，精通困难”的一部分知识。深刻理

解 HTML 是成为优秀的前端工程师重要的一步。

我们在上一篇文章中讲到了，HTML 的标签可以分为很多种，比如 head 里面的元信息类标

签，又比如 img、video、audio 之类的替换型媒体标签。我今天要讲的标签是：语义类标签。

语义类标签是什么，使用它有什么好处？

语义类标签也是大家工作中经常会用到的一类标签，它们的特点是视觉表现上互相都差不多，

主要的区别在于它们表示了不同的语义，比如大家会经常见到的 section、nav、p，这些都是

语义类的标签。

语义是我们说话表达的意思，多数的语义实际上都是由文字来承载的。语义类标签则是纯文字

的补充，比如标题、自然段、章节、列表，这些内容都是纯文字无法表达的，我们需要依靠语

义标签代为表达。

在讲语义之前，我们来说说为什么要用语义。

现在我们很多的前端工程师写起代码来，多数都不用复杂的语义标签， 只靠 div 和 span 就能

走天下了。

这样做行不行呢？毫无疑问答案是行。那这样做好不好呢？按照正确的套路，我应该说不好，

但是在很多情况下，答案其实是好。

这是因为在现代互联网产品里，HTML 用于描述“软件界面”多过于“富文本”，而软件界面

里的东西，实际上几乎是没有语义的。比如说，我们做了一个购物车功能，我们一定要给每个

购物车里的商品套上 ul 吗？比如说，加入购物车这个按钮，我们一定要用 Button 吗？

实际上我觉得没必要，因为这个场景里面，跟文本中的列表，以及表单中的 Button，其实已

经相差很远了，所以，我支持在任何“软件界面”的场景中，直接使用 div 和 span。

不过，在很多工作场景里，语义类标签也有它们自己无可替代的优点。正确地使用语义标签可

以带来很多好处。语义类标签对开发者更为友好，使用语义类标签增强了可读性，即便是在没

有 CSS 的时候，开发者也能够清晰地看出网页的结构，也更为便于团队的开发和维护。除了

对人类友好之外，语义类标签也十分适宜机器阅读。它的文字表现力丰富，更适合搜索

引擎检索（SEO），也可以让搜索引擎爬虫更好地获取到更多有效信息，有效提升网页的搜

索量，并且语义类还可以支持读屏软件，根据文章可以自动生成目录等等。不过，不恰当地使

用语义标签，反而会造成负面作用。这里我们举一个常见的误区作为例子。我们都知道 ul 是

无序列表，ol 是有序列表，所以很多接触过语义这个概念，半懂不懂的前端工程师，特别喜欢

给所有并列关系的元素都套上 ul。实际上， ul 是长成下面的这种样子的 (以下来自 HTML 标准)。

I have lived in the following countries:

• Switzerland
• Norway
• United Kingdom
• United States

ul 多数出现正在行文中间，它的上文多数在提示：要列举某些项。但是，如果所有并列关系都

用 ul，会造成大量冗余标签。错误地使用语义标签，会给机器阅读造成混淆、增加嵌套，给

CSS 编写加重负担。所以，对于语义标签，我的态度是：“用对”比“不用”好，“不

用”比“用错”好。当然了，我觉得有理想的前端工程师还是应该去追求“用对”它们。

与 JavaScript 这样严格的编程语言相比，HTML 中语义标签的使用更接近我们平常说话用的

自然语言。我们说话并没有唯一的标准措辞，语义标签的使用也是一样。下面，我挑选了几种

（我认为）比较重要的语义标签使用场景，来为你介绍一下。

作为自然语言延伸的语义类标签其实语义问题不仅仅属于理科，它还是个文科问题。所以我们

这里讲语义标签的使用的第一个场景，也是最自然的使用场景，就是：作为自然语言和

纯文本的补充，用来表达一定的结构或者消除歧义。

我们先来看看“表达一定的结构”这个场景。在日语中，有一个语法现象叫做：ルビ，它的读

音是 ruby（著名的 ruby 语言就是据此命名的），它中文的意思大约类似于注音或者意思的注

解，它的形式可以看下图：图中的例子选自动画片《某科学的超电磁炮》第二季第一话。图中

把 teleport 放在空间移动上方的用法，就是日文中 ruby 的用法。“空间移动”是动画中白井

黑子的技能，这里动画字幕上写的是“空间移动”，动画里的台词则用了英文发

音“Teleport”，这里就形成了一个使用

ruby 的场景。ruby 的这个形式，在中国的网友中间最近被玩出了新花样，比如表情包。

有时候微信聊天，不能用 ruby 这样的东西真的是好急啊，只好用括号代替，效果真是差了不

少。在 HTML5 中，就引入了这个表示 ruby 的标签，它由 ruby、rt、rp 三个标签来实现。

所以说，这些情况里存在的语义，其实原本就存在了，只是我们用纯文字是没法表达的，

HTML作为一种“超文本”语言，支持这些文字表达就是必要的了。还有一种情况是，HTML

的有些标签实际上就是必要的，甚至必要的程度可以达到：如果没有这个标签，文字会产生歧

义的程度。

这里我们可以介绍一下 em 标签。

我们看看这句话，

1. 今天我吃了一个苹果.

再比如：

昨天我吃了一个香蕉。

今天我吃了一个苹果。

看上去它很清楚，但是实际上，这句话放到不同上下文中，可能表达完全不

同的意思。

昨天我吃了两个苹果。

今天我吃了一个苹果。

试着读一读，这两段里面的“今天我吃了一个苹果”，你是不是发现读音不自觉地发生了变化？

实际上，不仅仅是读音，这里的意思也发生了变化。前一段中，表示我今天吃的是苹果，而不是别的什么东西，后一段中，则表示我今天只吃了一个苹果，没有多吃。

当没有上下文时，如何消除歧义呢？这就要用到我们的 em 标签了。em 表示重音：

通过 em 标签，我们可以消除这样的歧义。

一些文章常常会拿 em 和 strong 做对比，实际上，我们只要理解了 em 的真正意思，它和

strong 可谓天差地别，并没有任何混淆的可能。

作为标题摘要的语义类标签

介绍完自然语言的语义场景后，我想介绍的另一个语义重要使用场景，就是文章的结构。中国古

代小说就形成了“章 - 回”的概念，西方的戏剧也有幕的区分，所以人类的自然语言作品也是如出一辙。

HTML 也应该支持这样的需求。HTML 语义标签中，有不少是用于支持这样的结构的标签。

语义化的 HTML 能够支持自动生成目录结构，HTML 标准中还专门规定了生成目录结构的算

法，即使我们并不打算深入实践语义，也应该尽量在大的层面上保证这些元素的语义化使用。

首先我们需要形成一个概念，一篇文档会有一个树形的目录结构，它由各个级别的标题组成。这

个树形结构可能不会跟 HTML 元素的嵌套关系一致。

这段 HTML 几乎是平铺的元素，但是它的标题结构是：

HTML 语义

弱语义

今天我吃了一个 <em> 苹果 </em>。

今天我吃了 <em> 一个 </em> 苹果。

例如：

端开发人员可能都遇到这种情况，有时候我们想把div的高度像设置宽度一样设置成占网页的百分之多少，却发现高度百分比并不起效。

比如我们想让一个div的宽度为50%，高度为50%，很自然的写出：

可结果发现宽度为50%，高度却不起作用。

查阅很多资料后，终于找到了解决办法。问题就在于浏览器计算高度和宽度的方式不同：

Web浏览器在计算有效宽度时会考虑浏览器窗口的打开宽度。如果你不给宽度设定任何缺省值，那浏览器会自动将页面内容平铺填满整个横向宽度。

但是高度的计算方式完全不一样。事实上，浏览器根本就不计算内容的高度，除非内容超出了视窗范围(导致滚动条出现)。或者你给整个页面设置一个绝对高度。否则，浏览器就会简单的让内容往下堆砌，页面的高度根本就无需考虑。

因为页面并没有缺省的高度值，所以，当你让一个元素的高度设定为百分比高度时，无法根据获取父元素的高度，也就无法计算自己的高度。换句话说，父元素的高度只是一个缺省值：height: auto;。当你要求浏览器根据这样一个缺省值来计算百分比高度时，只能得到undefined的结果。也就是一个null值，浏览器不会对这个值有任何的反应。

上面的演示例子是父元素没有设定固定高度，于是子元素的高度height: 50% 也不会起作用。解决办法就是给html和body加上height: 100%。

运行结果如下，得到我们想要的结果。

总结：高度百分比只有在父元素高度固定的情况下生效，利用宽高百分比，实现响应式布局。另外如果你的元素实际高度大于你设定的百分比高度，那元素的高度会自动扩展。

我是竹风，欢迎订阅关注我，玩转前端，带你体验不一样的前端世界。