前端二向箔-HTML

本文最后更新于：2021年3月31日 下午

绪论 系统化前端知识复盘

我的疑惑

本人接触编程到学习前端知识, 估摸已有近一年多时间, 在这个过程中遇到了一些常见的问题:

  • 知识碎片化, 即使学习了大量的知识, 也有进行一些实战操作, 但很多时候知识系统一片混乱
  • 即使使用了一些管理工具, 如onenote\博客\notion等, 仍然觉得自身整理的内容缺乏条理和价值
  • 难以坚持, 在进行了约3-4个月的博客记录后, 之后频率降低, 有学习抵触心理
  • 前景的思考, 前端的价值何在, 如何提升自身核心竞争力, 以及职业生涯成长规划如何. 相比之下, 后端较多情况下就是业务核心, 而前端大多是附属增值手段.

思考原因

很多问题无法回避, 这里面主要是入门后的迷茫感和价值取向. 众口纷云的”35岁危机”绝不是空穴来风. 这种双重的疑问很容易造成对自身学习能力和目的的怀疑. 我是否真的适合这行当? 我是否真该选择做前端?

很大程度上几个疑惑是相互关联的, 主要是因为反馈结果不良, 造成热情低能状态, 进而没有很好地组织知识框架. 或者组织了知识框架, 缺乏规律性\科学的复盘计划, 也会得不偿失. 这有许多原因, 如个人网站曝光不够\自身文章质量不佳\缺乏自己的提炼思考, 为了记录而记录.

前端价值何在?

本文不是吹毛求疵, 更不是贬低前端价值.

确实, 在我所认知的编程行业中, 前端即使脱离的机械性\大量的基础操作, 近年来也有优秀的工程化项目发展壮大, 但似乎许多东西还是拿来做着以前一样的事情, 只不过是换了种方式表达. 那似乎前端无法摆脱自身的枷锁, 向更高价值区间跃进. 特别是在分工明确的团队中, 美工\UI将用户体验基本完成, 而前端的价值似乎又被瓜分, 在其中只做一个效率中间件. 而不管在大厂还是小厂, 这种局面似乎普遍存在, 望求解.

这种想法一定程度上受限于我个人的知识和经验, 前端发展势不可挡, 而且它还很年轻, 潜力还有许多可以发掘, 但这些质疑也应当被每个学习前端的深思过. 前端的价值何在? 个人所见, 于商业上, 高效\多端可靠\用户交互做到完美符合用户需求; 于技术上, 改变信息的传播, 以极具创造力的方式来为生活\生产带来质的变化. 前端首先是个工程师, 然后是个前端, 说到底, 对于俗人来说, 这全都是谋生的手段. 放大来讲, 更不应该局限于前端这个标签, 应去了解学习编程世界的全貌, 纵横捭阖才观得大势. 要向着高层框架的角度去思考前端移动展示和用户交互而前进, 而非做个思想的螺丝钉, 一心一意切页面.

复盘

选择在博客平台进行表达, 进行复盘, 精进与勉励. 计划在1~2个月内完成前端复盘工作, 说是复盘, 更多的是自我检查和自省.

复盘主要解决的是知识点由散乱到连线成面的过程. 做好自身的管理, 协调时间提升自己, 形成系统化的前端知识体系, 建立学习的方法论. 不在被动式地焦虑疑惑.

复盘也将更多的在每一门技术的价值\背景\设计思想的角度出发. 而不是简单的用法记录, 那样无异于无意义学习. (而且还灌水)

诸君共勉.

01 学习路线RoadMap

00 绪论 系统化前端知识复盘

我学前端的核心思想

大多数大学是不会将前后端之类具体职业设立为专业的, 即使开设有前端相关课程, 较多都是以jsp和一些接近过时的网页开发知识. 原因有二: ①高校培养人才目的不是为了岗位培养, 而是为了综合性的指标, 个人成长, 社会价值和行业发展. ②前端变化太快了, 大学老师旨在授课于知识的方法论和处世之道, 而非培训班, 更与教学育人的属性有出入.

即使如此, 有个很矛盾的地方, 就是前端的顶尖人才匮乏, 这个职业很年轻, 潜力无限, 需要有着高水平和创新力的人才. 奈何于大学专业授课的属性相悖, 导致没有系统的教学方案人才培养计划, 大多数都是依靠自学, 或者培训班. 缺乏系统的知识体系就难以维系大量的知识积累和实践. 结果就会出现前端过热, 却仍然没有多大突破性的发展.

所以, 要立志高远, 格物致知. 不要陷入重复性\无意义劳动的陷阱, 这样只会固步自封. 保持持续学习的能力是任何一个人在行业中精进的核心. 也不要局限于岗位之上, 吃饭固然重要, 如何利用自身资源和优势, 去实现更高的目标, 而非办公室一隅孤芳自赏.

目标

  • 建立系统的前端知识结构体系, 锻炼工程师素养
  • 完善学习编程的方法论
  • 技术的核心思想的理解
  • 学习交流, 自检

组织形式

常见网络知识博客组织形式都是以某个技术热点为展开, 这样有个弊端, 较难从语言\数据结构\性能架构的层次去理解知识. 而且缺乏相关的逻辑关联, 导致即使学了很多, 也看懂了, 间歇性地遗忘地问题, 显然这种形式对构建知识体系并不友好.

web前端核心就是Javascript语言, 对于语言, 可以以语言地学习规律去串联各个技术点. 特别是Javascript, 可以从语言的结构, 运行环境和执行三部分去组织, 向下引伸可以是基础语法\内存\数据结构-堆, 栈\事件等.

对于一些html和css, 此类标记语言和样式语言, 组织形式尤为重要. html要考察其合理性\语义化\分类归纳, css一方面是美学素养, 对于前端工程师, 更重要的是高性能的架构, 可靠的兼容性\交互效果, 所以要着重理解其设计模式.

之后是一些常见API和计算机网络知识, 这一部分主要是考察应用和理解. 其中, 浏览器模型需要了解其实现原理, 并与API, 网络技术相互关联, 深化架构体系

最后才是一些关键技术问题和热点, 如前端工程化, 前端框架探讨, 以及面试问题的收录.

RoadMap-来自github

  • 一份来之gayhub的高星前端技术路线 link↗
  • 查看我的notion整理页面: link↗
  • 可能有更新, 可以上GitHub查看最新版
  • 可以作为参考, 进行遍历学习或者复盘, 当然要结合我之前的组织形式进行构建体系, 这些远远不够, 需要更加主动地收集知识管理的方法论\模型, 整理出自己的架构.
  • 一边写一边尝试知识的组织信息

road

02 HTML语义化

语义化标签应该是HTML5基本的规范要求, 对于良好的web语义化, 不单是说表义上理解的标签语义, 语义化最大的好处是方便机器识别. 特别是在一些视障人群和阅读模式的适配. 良好的语义化更有利于网页SEO, 增加曝光.

这些应该是初级入门时了解到的语义化的相关程度. 而对于深入一些, 应该对于语义化有业务场景结合的思考.

当然, 个人认为, 要真正理解并运用语义化, 还要对HTML内容分类有较深入了解, MDN已有优质wiki🔗

不求一丝不苟, 只需因地制宜

刚开始入门的时候, 语义化的实施要么一丝不苟地严格使用, 要么零散分布, 想起来的时候就用上. 但一段时间后大多不会在语义上有太多讲究, 用的最多地就是header section nav 等常见标签.

事实上, 花费时间过渡琢磨和不讲究都不是语义化的良好实践. 在应用层面上, 也许**div和span加上class完全可以完成业务需求**, 而且对于性能表现也不会有太大影响. 语义化更多的用处是在wiki页面上, 这类网页有良好的阅读目的, 因此语义化较为重要.

反而错误使用语义化标签会导致负面影响, 如常见的, ul ol, 前者表并列, 后者表顺位. 还有用div和span去交错包裹形成混乱的嵌套, 对浏览器阅读识别很不友好.

因此, 对于语义的使用, 是需要确保可以合理的组织运用, 保持语义化结构不被平铺的div和span打断.

接下来分析一下如何实践语义化规范.

基于wiki类型的语义化例子

此类网页语义化内容并不多, 无非是围绕文章内容呈现而定制地几个标签结构.
一个典型地wiki详情页的body应该有以下结构, 常用于博客, 新闻界面类型的网页应用.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<body>
    <header>
        <nav>...</nav>
    </header>
    <aside>
    	<nav>...</nav>
    </aside>
    <main>
        <h1></h1>
        <article>
            <header>...</header>
            <section>...</section> 
            <footer>...</footer>
        </article>
    </main>
    <footer>
        <address></address>
    </footer>
</body>

接下来以MDN↗为例, 结合上述Sample, 对于语义化进行阐述.

image-20210211232520414

👆非实际页面结构, 辅助理解

如何优雅地使用

整体可以拆分为结构元素和内嵌元素, wiki页面追求SEO, 传播目的性强, 需要组织成良好的语义化网页.

1. 结构元素

网页头部, 展示介绍性的内容, 辅助工具等, 也常用于包裹标题组合.

image-20210211230200731

aside

侧边栏, 工具类, 导航, 于页面内容独立且不影响主体

image-20210211233102497

main

main表示的内容要求独立性, 且具有分段意义, 因此, 对于网页上独立的内容需要用main概括.

article

article相比main强调的是媒体内容, 特别是新闻传播中有独立意义的文章.

image-20210211234457735

section

section并没用较明确的语义, 一般就作组成部分. 可以用作

  • 文档大纲概要, 一般包括一个标题和文字描述
  • 文章内容分段

image-20210212121628861

footer分为article的和body的, 主要职能就是展示脚注, 引用目录, 附加信息, 地址邮件等.

image-20210212121917346

2. 内嵌元素

  • h1~`h6 \hgroup`: 一般h1\h2再用hgrop包裹就是一个基本的标题组, 还可在html中生成目录结构

  • nav –导航标签, 用于链接页面形成目录索引, 内部有ol\ul和li.

  • strong和em, b和i 的异同:

    • b、i属于修饰类标签；strong、em属于内容类标签

    • b、strong标签表现为加粗；em、i表现为倾斜

    • strong、em表强调；strong比em语气更强烈；strong在页面上的强调，而em是更多在语义上强调

    • strong和em真正做到了结构与样式分离，而b、i没有做到结构与样式的分离

    • 在搜索引擎优化strong和em比b和i重要的多。

  • figure –图表, 和figcaption 描述一起使用, 用于描述独立的图片与文字组合.

  • cite –引用, 在论文中常见.

  • mark –高亮, 读者角度, 高亮文本.

  • detail –挂件, 形式为下拉菜单. 和summary提供概要.

  • time –时间, 可以让机器阅读更加方便.

  • pre –预定义格式输出, 不改变排版, ( 输出字面量标签要更换为转义符, 如’<’👉&lt ).

    • samp–代码示例, 一般用于表示程序输出信息\非代码的程序部分.
    • code –源代码.

可见, 结构元素以一条完整的主线, 串联起各个部分, W3C专家倡导的文字排版应用在web上, 体现web作为信息传播的重要途径和文字排版学问的广博.

跑偏了, 我们要把握基本的结构, 再适当地使用内嵌其中的语义化标签, 形成良好的规范和结构.

建议

语义化是相对简单地一个知识点, 本文不是在介绍各个标签的详细用法, 也并没有列出全部语义标签. 旨在标出个人认为形成语义化规范的重要且基础的部分.

是否要严格执行语义化, 要根据具体的业务需求, 对于传播目的性强\团队协作\规范严谨的一类网页可以加强这方面的实施, 对于功能目的性强的\业务效率优先的网页则可以简化. 语义化本身有些争议, 这是文本标记语言的特性决定的, 不像其他编程语言一样需要非常严谨的逻辑和规则.

当然, 文中提到的只是wiki文章中典型的语义化要求, 也可以抽象出通用的语义化要求:

  • 文本层面语义化
  • 结构层次的语义化

本文提供语义化思想的方法论, 届时更新更加深入的语义化优化方案.

03 HTML元数据和链接

html元数据即在head标签中的部分, 主要是描述了网页的一些重要的信息和媒体链接. 大多情况下是提供给浏览器爬虫和机器阅读的. 链接作为网页的互联的基石, 在head中链接有link和script两种形式.

本文归纳常见的元数据和链接的重要知识.

元数据

  • head

    head本身没有意义, 只提供保存容器, 是Document的元数据集合. 不会在页面上显示, 且只有一个title和base.

  • title

    网页html文档标题, 而非网页内容标题( h1~h6), 主要在搜索中体现重要性, 对于整个文档的概括性. 这个标题在其他上下文中也会被使用，例如在用户的历史、书签，或搜索结果中

  • base

    给网页上的URL提供相对地址的基础, 相当于根目录前缀, 只能有一个base. 它会改变全局的链接, 并不提倡使用.

    1
    2
    3
    <base href="https://www.example.com/news/index.html">
    ...
    <p>Visit the <a href="archives.html">archives</a>.</p>

    上面例子中的链接地址是 “https://www.example.com/news/archives.html“。

  • style

    css样式表

最重要的meta

meta是作为title, base, link等的补充, 而实际上meta类型是开发者常见的优化方向. 本质是key-value.

使用meta要注意:

  • 必须指定任意一个: name，http-equiv，charset， 和 itemprop( 除了itemprop其他的都要同时指定content)
  • 每个文档必须存在不少于一个有 charset 属性的 meta 元素。

可以自定义meta, 约定好name和value即可, 也可以使用预定义的规范meta.

主要预定义的类型有这几项:

  1. html5简化了meta的charset写法, 新增charset属性用于设置网页的编码. 即:

    1
    <meta charset="UTF-8">

    进行utf-8(ASCII是utf-8的子集)编码是因为一般http请求过程, 服务器会设定编码格式, 但应对一些非http协议无请求头, 如file, 就可以避免乱码情况.

  2. 具有http-equiv属性的meta, 执行命令, 一般是添加http头, 即content-type, 可以同时设定编码:

    1
    <meta http-equiv="content-type" content="text/html; charset=utf-8">

  3. name为viewport的meta, 设置网页缩放, 响应式设计中最常用.

    1
    <meta name="viewport" content="width=device-width,initial-scale=1,minimum-scale=1,maximum-scale=1,user-scalable=no">

    上述是移动端响应式设计中最典型的使用, 其中content设置key=value, 中间使用逗号分隔.

    属性解释:

    • width：页面宽度，可以取数值，一般设置成 device-width，即设备宽度。
    • height：页面高度，可以取数值，一般设置成 device-height，即设备高度。
    • initial-scale：初始缩放比例. (一般为1)
    • minimum-scale：最小缩放比例。 (一般为1)
    • maximum-scale：最大缩放比例。 (一般为1)
    • user-scalable：是否允许用户缩放。(对于移动端已有响应式设计就设置为no)

  4. description\application-name, 前者描述网页, 后者提供网页应用的名称

    1
    2
    <meta name=application-name content="mugu">
    <meta name="description" content="this is a description>

    对于description, 在网页搜索中比较重要, 对于信息的提取也比较高效

    而application-name是为网页应用设置的, 可以用作标签收藏时的使用, 利于浏览器算法生成.

  5. keyword弃用, 很多搜索引擎不会考虑这些关键字，因为该特性是不可靠的甚至会导致垃圾结果，对用户并没有帮助。特别是面对一些作弊, 恶意填充的keyword, 浏览器搜索引擎基本不作为考量.

  6. referrer, generator, theme-color……

链接

链接包括两种, 超链接和外部资源链接, 其中核心就是互联网的URL和URI系统.

URI 指的是一个资源，URL 指的是用地址定位一个资源，URN 指的是用名称定位一个资源。 即URL 和 URN 是 URI 的子集。 详细可见引用[4]

在网页中链接最重要的两个属性是rel和href, 前者是Relationship, 指链接目标文档和本文档的关系; 后者表示Hypertext Reference, 指超链接的目标地址. 把握这两者的对应关系可以更好的理解和使用响应的标签.

网页中的链接主要有以下:

  1. rel属性, 不同的功能

link最主要的使用时链接外部资源. 即外部资源类链接. 常见在head标签中, 进行stylesheet关系的css文件引用.

1
<link rel="stylesheet" type="text/css" href="theme.css">

大多情况向link不会显示在网页中, 作为元数据的一类, 其设计的目的是为了浏览器和搜索引擎识别. 比如icon资源, 会被浏览器识别:

1
2
3
4
<link rel="alternate" type="application/atom+xml" href="/blog/news/atom">
<!-- 移动端提供不同分辨率, 此处的apple开头rel为ios特有 -->
<link rel="apple-touch-icon-precomposed" sizes="114x114" href="favicon114.png">
<link rel="apple-touch-icon-precomposed" sizes="72x72" href="favicon72.png">

此外指定不同的rel可以有不同的功能, 如preload预加载一些资源文件( 只是缓存, 未执行, 同常加上type属性声明MIME类型 ); 使用prerender可以预渲染页面, 这在确定用户会接下的页面中设置, 来访问可以极大提升用户体验.

1
2
<link rel="preload" href="sintel-short.mp4" as="video" type="video/mp4">
<link rel="prerender" href="http://example.com/">

as属性指定加载资源的类型，它的值一般有下面几种。

  • script
  • style
  • image
  • media
  • document

还有一些其他信息类的元数据用途, 即提供给搜索引擎\浏览器等, 此类一般为超链接类链接, 当rel指明为:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
<!-- 作者信息 -->
<link rel="author" href="humans.txt">

<!-- 版权信息 -->
<link rel="license" href="copyright.html">

<!-- 另一个语言的版本, 通常由搜索引擎判别; 也可由插件判断RSS订阅链接 -->
<link rel="alternate" href="https://es.example.com/" hreflang="es">
<link rel="alternate" type="application/atom+xml" href="/blog/news/atom">

<!-- 联系方式 -->
<link rel="me" href="https://google.com/profiles/someone" type="text/html">
<link rel="me" href="mailto:name@example.com">
<link rel="me" href="sms:+15035550125">

<!-- 历史资料 -->
<link rel="archives" href="http://example.com/archives/">

<!-- 目录 -->
<link rel="index" href="http://example.com/article/">

<!-- 导航, 主要在分页浏览的业务场景中 -->
<link rel="first" href="http://example.com/article/">
<link rel="last" href="http://example.com/article/?page=42">
<link rel="prev" href="http://example.com/article/?page=1">
<link rel="next" href="http://example.com/article/?page=3">

<!-- 部分来自wangdoc.com -->

当然有些已经被meta元数据替代.

  1. media属性, 外部资源生效的媒介条件

    1
    2
    <link href="print.css" rel="stylesheet" media="print">
    <link href="mobile.css" rel="stylesheet" media="screen and (max-width: 600px)">

    和css的媒体查询类似, 在不同条件下, 加载不同的文件资源.

  2. 其他属性

    <link>标签的其他属性如下。

    • crossorigin：加载外部资源的跨域设置。
    • href：外部资源的网址。
    • referrerpolicy：加载时Referer头信息字段的处理方法。
    • as：rel="preload"或rel="prefetch"时，设置外部资源的类型。
    • type：外部资源的 MIME 类型，目前仅用于rel="preload"或rel="prefetch"的情况。
    • title：加载样式表时，用来标识样式表的名称。
    • sizes：用来声明图标文件的尺寸，比如加载苹果手机的图标文件。

a

a标签指anchor, 即锚点, 在网络中定下信标就是a标签的功能. a标签于link同样具有rel和href, 也可充当元数据, 且rel的:

alternate \ author \ help \ license \ next \ prev \ search

与link的语义相同, 不同的是, a会显示在页面上, 更多是阅读用途.

除了常用的链接, 还有几个比较重要的用法:

  • download属性, 表示当前链接用于下载, 如下例, 文件名为bar.exe, 也可省略.

    1
    <a href="foo.exe" download="bar.exe">点击下载</a>

    注意，如果链接点击后，服务器的 HTTP 回应的头信息设置了Content-Disposition字段，并且该字段的值与download属性不一致，那么该字段优先，下载时将显示其设置的文件名。

  • mailto协议, 打开本机默认的邮件程序发送邮件

    1
    2
    3
    4
    5
    6
    7
    8
    9
    <a href="mailto:contact@example.com">联系我们</a>

    <!-- 详细用法可以指定邮件的主题\日期等, 注意需要转义, %20为空格 -->
    <a
      href="mailto:foo@bar.com?cc=test@test.com&subject=The%20subject&body=The%20body"
    >发送邮件</a>

    <!-- 分享网页的用法 -->
    <a href="mailto:">告诉朋友</a>

script

作为交互的灵魂, script标签加载脚本代码, 执行JavaScript程序.

最重要的就是type属性, 一般默认是”text/javascript”. 还有下面一些其他属性，大部分跟 JavaScript 语言有关.

  • async：该属性指定 JavaScript 代码为异步执行，不是造成阻塞效果，
  • JavaScript 代码默认是同步执行。
  • defer：该属性指定 JavaScript 代码不是立即执行，而是页面解析完成后执行。
  • crossorigin：如果采用这个属性，就会采用跨域的方式加载外部脚本，即 HTTP 请求的头信息会加上origin字段。
  • integrity：给出外部脚本的哈希值，防止脚本被篡改。只有哈希值相符的外部脚本，才会执行。
  • nonce：一个密码随机数，由服务器在 HTTP 头信息里面给出，每次加载脚本都不一样。它相当于给出了内嵌脚本的白名单，只有在白名单内的脚本才能执行。
  • referrerpolicy：HTTP 请求的Referer字段的处理方法。

<noscript>标签用于浏览器不支持或关闭 JavaScript 时，所要显示的内容. noscript不是一个功能性标签, 我个人感觉更像是一种人性化的设计, 虽然有些争议, 但是在某些层面noscript照顾到一部分人的利益. 可以查阅这篇博客🔗I Used The……[5]

要注意的是href和src虽然都是提供了URL, 但是两种用本质区别, 即前者为替换型标签, 引入资源后替换自身, 如script. 但href则是链接到外部的标签.

那为什么style标签不能像script一样使用src呢? 而是要link链接? 下篇博客详细讨论相关内容和媒体标签的引用.

以上为链接相关的内容.

引用

  1. HTML Standard. (2021). Retrieved 18 February 2021, from https://whatwg-cn.github.io/html
  2. 文档级元数据元素 - HTML（超文本标记语言） | MDN. (2020). Retrieved 18 February 2021, from https://developer.mozilla.org/zh-CN/docs/Web/HTML/Element/meta
  3. 链接标签. (2021). Retrieved 19 February 2021, from https://wangdoc.com/html/link.html
  4. URI、URL 和 URN 的区别. (2019). Retrieved 19 February 2021, from https://juejin.cn/post/6844904003348725767
  5. I Used The Web For A Day With JavaScript Turned Off — Smashing Magazine. (2018). Retrieved 19 February 2021, from https://www.smashingmagazine.com/2018/05/using-the-web-with-javascript-turned-off/

04 HTML嵌入型元素(媒体标签)

上篇博客提到了链接, 主要讲述的是link, a, script等链接型元素. 与之相对的是嵌入在网页中的内容, 嵌入内容对应的嵌入型元素主要是一些多媒体标签. 它们主要是img, video, audio, iframe等. 本文一一复盘.

为什么style标签没有src?

开始复盘前, 先理解一下嵌入型和链接型的区别.

image-20210220221057875

相关tweet中, 老哥的这段话的大意是: 网页中某个具有src属性的标签, 是让浏览器去引用并嵌入到这个标签的位置.

而从功能角度思考, stylesheets作用在整个文档, 和文档是有对应的, 明确的1对1的映射关系. 而非其他嵌入在其中的包含关系. 所以, 有以下可能的原因和结论:

  • style标签与页面不是嵌入关系, 故没有src, 至于为什么没有href, 而是用link来描述样式表, 可能是

    • 有一定的历史遗留和设计原因, 起初的css发展和html不同步, 可能有设计层面的原因
    • link更能抽象和描述样式表这一外部文件和文档的关系.

  • 包含src的元素是嵌入型, 包含href的是链接型元素

其实, script标签和页面也可以归纳为一种对应关系, 应该也可以使用link去引入. 但是个人认为, 从浏览器工作层面考量则应更注重内联和引用的层面. 所以部分知识有争议和待求解很正常, 需要用辩证, 客观的想法去学习, 没有本来就那样的道理, 学会从语言设计层面去思考问题.

嵌入型多媒体标签

  1. img

    img是大家非常熟悉的标签了, 基础略过, 一些重要的属性和优化如下:

    • alt

      alt这个属性一般用户没有什么感受, 最多在图片加载失败时候, 看到一张破碎的图标和”img”的字样.

      事实上, alt是对于视障人士最大的关怀. alt可以放置描述性的文字用以机器阅读, 是特别重要但又容易被忽略的一点.

      1
      <img src="foo.jpg" alt="一只小狗在奔跑">

      正确的alt应该是如上面所示, 描述图片, 而非”图片”, “示例图片”, 这也是容易被忽略的. 这是做到网址可达性的重要一点.

    • loading

      设置懒加载, 对于浏览较多, 较长的图文会非常有用, 只有当用户交互到的时候才进行加载, 即节省带宽流量, 有提高网页加载速度.

      loading属性可以取以下三个值。

      • auto：浏览器默认行为，等同于不使用loading属性。
      • lazy：启用懒加载。
      • eager：立即加载资源，无论它在页面上的哪个位置。

      由于图片的懒加载, 会导致页面重排, 影响性能. 所以一般设置好宽高.

      1
      <img src="image.png" loading="lazy" alt="…" width="200" height="200">

    • data uris

      这类data:uri的图片引入也是常用的技巧, 用来减少文件的引入, 从而减少http请求, 提升网页性能. 替换调url为data uris. 格式如下

      1
      data:[<mime type>][;charset=<charset>][;base64],<encoded data>

      常见的就是base64的图片编码:

      1
      <img src="data:image/gif;base64,R0lGODlhEAAQAMQAAORHHOVSKudfOulrSOp3WOyDZu6QdvCchPGolfO0o/XBs/fNwfjZ0frl3/zy7////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAkAABAALAAAAAAQABAAAAVVICSOZGlCQAosJ6mu7fiyZeKqNKToQGDsM8hBADgUXoGAiqhSvp5QAnQKGIgUhwFUYLCVDFCrKUE1lBavAViFIDlTImbKC5Gm2hB0SlBCBMQiB0UjIQA7" alt="star" width="16" height="16">

      可以通过一些在线的网址提取图片的base64编码, 比如这个online base64 converter

      转换后base64的图片相比原来的可能会增加30%的大小, 因为通过较长的字符串来替代, 所以会降低可读性, 同时如果写在css中, 会增加css的体积, 但是可以通过压缩解决这个问题. 但是用base64有更明确的场景条件:

      • 被编码的图片较小, 且复用性高, 不经常刷新. 如用50X50字节的图片去平铺背景图
      • 不用额外的请求
      • 无法使用cssSprite的独立性较高的图片.

      特别是数量大, 独立性强, 体积小的图片. 这点和cssSprite比较像, 但两者还是有区别的. 可以参考这位博主的分析, 图片Base64编码的利与弊分析.

      不要盲目使用base64, 不是说可以减少图片请求就可以提高网页速度, 要因地制宜地使用, 否则:

      image-20210221111951829

      (应该是主要用base64)加载图片的网址比单纯使用二进制链接(即src等)的网址慢了6倍!

    • srcset, sizes

      srcset可以为图片设置不同url地址, 主要用于移动端的响应式设计, 采用不同的图片尺寸来实现.

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      <img srcset="foo-160.jpg 160w,
                   foo-320.jpg 320w,
                   foo-640.jpg 640w,
                   foo-1280.jpg 1280w"
           sizes="(max-width: 440px) 100vw,
                  (max-width: 900px) 33vw,
                  254px"
           src="foo-1280.jpg"><img srcset="foo-320w.jpg,
                   foo-480w.jpg 1.5x,
                   foo-640w.jpg 2x"
           src="foo-640w.jpg">

      srcset属性给出了三个图像 URL，适应三种不同的像素密度.

      图像 URL 后面的像素密度描述符，格式是像素密度倍数 + 字母x。1x表示单倍像素密度，可以省略。浏览器根据当前设备的像素密度，选择需要加载的图像。

      如果srcset属性都不满足条件，那么就加载src属性指定的默认图像。

      而 sizes属性, 则是用于选择不同的屏幕宽度. 当不同尺寸的条件发生, 则显示不同宽度的图片.

      事实上, 更好的做法是使用picture标签. 同时兼具像素和屏幕选择的两种功能.

      1
      2
      3
      4
      5
      <picture>
        <source type="image/svg+xml" srcset="logo.xml">
        <source type="image/webp" srcset="logo.webp"> 
        <img src="logo.png" alt="ACME Corp">
      </picture>

  2. video

    去年正式歇菜Flash一度是web视频的独有者, h5播放器如今发展得越来越好. 一般来说, 会指定多个视频源:

    1
    2
    3
    4
    5
    6
    <video controls="controls" >
     <source src="movie.webm" type="video/webm" >
     <source src="movie.ogg" type="video/ogg" >
     <source src="movie.mp4" type="video/mp4">
     You browser does not support video.
    </video

    上面三种是video支持的主流视频格式. 分别是VP8 \ Theroa \ H.264对于的协议专利.至于为什么没有统一的h5的是视频格式, 可以追溯到各个厂家的竞争, 参考阮一峰翻译的HTML5的视频格式之争.

    不支持h5播放器就会显示标签中的内容. 同时可以参考各个属性进行设置, 参见MDN.

    audio属性基本和video一致.

  3. iframe

    iframe在网页开辟新的文档空间. 一般通过iframe嵌入其他网页. iframe并不被推荐使用, 一方面是网络安全问题, 容易利用iframe的漏洞进行攻击; 另一方面, 移动端显示问题, 还有诸多限制……此外还涉及到跨域问题. 一般网站都会通过http头禁止自身被设置为iframe.

    1
    <meta http-equiv="X-FRAME-OPTIONS" content="DENY">

    新标准增加了sandbox, 更加方便设置, 可以解决跨域问题, 权限管理等:

    sandbox属性可以设置具体的值，表示逐项打开限制。未设置某一项，就表示不具有该权限。具体可以查看MDN.

    注意，不要同时设置allow-scripts和allow-same-origin属性，这将使得嵌入的网页可以改变或删除sandbox属性。

参考引用

  1. Data URIs | CSS-Tricks. (2010). Retrieved 21 February 2021, from https://css-tricks.com/data-uris/
  2. Foskett, M. (2020). Image to base64 data-URI converter. Retrieved 21 February 2021, from https://websemantics.uk/tools/image-to-data-uri-converter/
  3. <img>：图像嵌入元素 - HTML（超文本标记语言） | MDN. (2020). Retrieved 21 February 2021, from https://developer.mozilla.org/zh-CN/docs/Web/HTML/Element/img
  4. 图像标签. (2021). Retrieved 21 February 2021, from https://wangdoc.com/html/image.html

05 HTML表格表单和ARIA

本篇博客大致回忆下表单表格的特点, 用法和注意事项. 还有重点复盘下ARIA系统的概念.

为什么不建议用要表格?

感兴趣可以先上StackOverflow查看这个当时table正火的帖子:

Why not use tables for layout in HTML? [closed]

你要是看了高赞的分析, 估计对table的弊端有大致的了解了. 个人认为web的发展并没有改变多少table的本质.

html的 table 元素表示表格数据 — 即通过二维数据表表示的信息 –MDN

table本意就是拿来渲染表格数据的, 按道理来说没什么问题, 各司其职. 但是主要涉及三个问题:

  • SEO和语义化问题, 事实上, table 并没有很好地语义化, 想象下, 大量的table 数据内容混杂, 用户搜索自然也不会集中到数据本身, 搜索权重自然就小. 而且本身的阅读性不是很好, 设计太过朴素难以突出重点, 特别是现在花里胡哨的网站中.
  • 可访问性(Accessibility)差, 特别在屏幕阅读和视障人群地使用中, 遇上大量数据很难阅读和被正确地识别. 基本措施是<caption>\ <summary>进行表格数据描述, 或是设置scope属性等.
  • 浏览器渲染性能问题, table 的性能一直被人们诟病. 特别是在渲染方面, 需要表格加载完毕才开始渲染布局, 会有明显的割裂感和延迟. 主要和浏览器的渲染算法有关, 特别应对大量数据时, 缓存也是个问题.

HTML设计思想是内容样式分离的, 使用CSS样式表来管理样式. 而这个table 却是兼具两者, 所以在浏览器行为方式不同也可以理解, 而且CSS更容易缓存. 目前table 的大量全局属性被抛弃MDN🔗 , 建议使用CSS管理样式, 也说明了W3C正在分解table .

不论怎样, 目前都是不建议使用table 进行布局的, 要我说直观点就是排版麻烦不好看, 还有各种小毛病XD.

基本用法可以参考阮一峰 表格标签🔗.

表单

表单可以说是学习web中第一个碰到交互最多的组件.

name 和id 的疑惑, 刚开始学习HTML的时候, 觉得name 和id 在大多数情况下的用途是一样的, 为什么不合并呢? 而在学习了form 之后, 才了解这样设计的部分原因.

  • label标签对应一个input, 关联的是input的id属性, 而非name属性, 此外除了常用的并列排布, 还可以包裹, 这是可以省略for和id属性:

    1
    2
    3
    <label>用户名：
      <input type="text" name="user">
    </label>

  • name 属性是关系到服务器的字段信息获取, 需要通过name来获取属性.
    此外表单的单选操作中会设置同个name .

基本用法参考阮一峰 表单标签🔗. 基础上没什么可以总结提炼的, 反观国内的框架也主要的是围绕表单优化展开. 而最重要的, 除了网络优化, 就是用户体验.

在用户体验方面, 可看看这篇博客 Form Design: 13 Empirically Backed Best Practices. 总结了一下重要的表表单开发和优化经验:

  • 少即是多, 减少输入框👇( 对比两图, 后面多清爽 )
    img
    image-20210225234802974

  • 单流向结构更易读, 更高效. 特别是移动端设备占主要成分的情况下.
    image comparing a single-column vs. multi-column form design.

  • 做好跟随的内联校验. 提高表单填写效率, 而非提交后才提示失败信息, 会严重挫败用户体验.

  • 设置自动聚焦, 特别是移动端

  • 增加显示密码, 有调查表明, 掩饰密码实际上没有对安全有多少影响, 反倒不变用户校验. 所以个人认为增加明文显示以供校验更加友好. can’k参考github的登陆界面:
    image-20210225235656213

此外, 还有两点值得注意:

  • 移除form表单默认跳转事件, form 和服务器打交道, 较多使用ajax技术进行提交, 为了防止默认的提交行为导致后续代码无法执行( 如弹窗, 回调函数等 ), 可以使用:

    1
    2
    3
    4
    5
    6
    7
    const submit = () => {
        //移除默认行为
        $('form').on('submit', e => {
            e.preventDefault();
            //ajax请求代码:
            //....
            })

  • 防止重复提交. 策略可以是页面跳转, 前端校验式添加锁机制( 用默个字段控制状态 ), 后端服务器字段校验等.

ARIA

ARIA全称: Accessible Rich Internet Applications 可访问富互联网应用, 即大家口中的无障碍, 是一个可访问性的标准. 有时候你会看到WAI-ARIA, 其中WAI = Web Accessibility Initiative, 即无障碍网页倡议. 两者指代的都是同意思.

可以把它当作HTML5标签的属性扩展. 主要可以支持屏幕阅读等辅助技术, 提供语义化信息.

现代浏览器基本支持ARIA, 即使不支持也不会造成问题, ARIA并不会改变标签的功能表现.

ARIA是在HTML4之后引入的, 更像是一个过渡时期的机制. 因为许多ARIA规范在HTML5中已经实现语义化标签, 但是仍然发挥着重要的补充功能.

ARIA不只是视障关怀

初识AIRA可能会误解为专为视障用户使用的关怀手段. 实际上, ARIA属于可访问性的范畴, 从语义化 \ 辅助阅读等角度都是AIRA的重点, HTML5实现相关ARIA属性为标签也可见一斑. 所以ARIA不只是特定用户的辅助技术, 更是衡量一个优秀网站的标准.

而且, 对于javascript程序为基础的web应用, 许多功能 \ 组件无法使用HTML标签去语义化表达, 这时候ARIA就发回了很大的扩展作用.

例如, 一个弹出式UI组件, 面包屑导航等在框架中常见的组件; 再从框架中的组件中也可以看出目前HTML没有的语义化表达.

实现原理和应用

ARIA 通过更改和补充标准 DOM 无障碍树来发挥作用。而且ARIA 不会补充元素的任何固有行为；

image-20210226173451402image-20210226173512018

通过DOM的修改\创建不存在HTML标签中的语义化元素, 大概可以实现以下功能:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<!-- 扩展语义, eg:创建了一的只读标签 -->
<button aria-label="screen reader only label"></button>

<!-- 定义父子组件的关系, eg:控制特定区域的自定义滚动条 -->
<div role="scrollbar" aria-controls="main"></div>
<div id="main">
. . .
</div>

<!-- 辅助技术API, eg:页面发生变化时立即通知辅助技术 -->
<div aria-live="true">
  <span>GOOG: $400</span>
</div>
......

role体系

ARIA 系统的其中一个核心层面是其role集。在无障碍术语中，角色是指特定 UI 模式的简略指示器.

换句话说, 可以将下面属性值理解成新的未纳入规范的语义化标签.

image-20210226112447841

可见, 有些role 在h5中成为了新标签( 图中红框圈出了部分 ), 把ARIA看出过渡也是一种观点.

看一看role 属性如何使用:

1
2
3
<div id="clock" role="timer" aria-label="tomato-timer" aria-roledescription="这是个番茄钟, 计时25分钟" tabindex="0">25mins</div>

<button onclick="startTimer('clock')">开始计时</button>

定义了timer这个计时器, 相关的aria- 属性让辅助手段判断其UI变化. 一般这种变化是通过js操作的, 而且aria- 更多在js应用中使用.

此处timer 对应的aria-label 描述其名称, aria-roledescription 添加更加具体的说明以供屏幕阅读器朗读等.

在WAI-ARIA中可以找到各个role 对应的属性 aria role🔗

role的使用很简单, 要更好地认识可以将其粗略分为widget部件和section组成:

  • widget
    • 功能型: button, alert, link, timer, progressbar, scrollbar, separator
    • 表单型: checkbox, radio, option, slider, slider, textbox, spinbutton
    • 复合型: tab, tree, menu, list, grid…..
  • section
    • h5中实现了很大一部分, 请直接使用. 如article,
    • Landmark, 直接翻译地标, ARIA标准中的八结构页面组成:
      • Banner ( 开发习惯常用banner头图 )
      • Navigation ( eg: nav标签, 导航栏 )
      • Form ( 表单 )
      • Main ( 主体 )
      • Application ( web应用本身 )
      • Search ( 搜索功能 )
      • complementary ( eg: aside标签补充说明, 辅助内容 )
      • contentinfo ( 内容注释, meta内容, 版权信息© )

AIRA的启发

可见, ARIA是更加抽象的标签, 对于理解网页结构, 文字排版等有重大的启发意义. 特别在进行组件设计时, 可以参考ARIA的设计思想, 由概念到属性, 进一步抽象, 封装成可用组件. 很多UI框架的组件就可以看成高一层的封装, 如各种tabbar\scroll-view\list等等.

引用

  1. <table>- HTML（超文本标记语言） | MDN. (2020). Retrieved 26 February 2021, from https://developer.mozilla.org/zh-CN/docs/Web/HTML/Element/table

  2. ARIA - 无障碍 | MDN. (2020). Retrieved 26 February 2021, from https://developer.mozilla.org/zh-CN/docs/Web/Accessibility/ARIA

  3. Introduction to ARIA | Web Fundamentals | Google Developers. (2021). Retrieved 26 February 2021, from https://developers.google.com/web/fundamentals/accessibility/semantics-aria#:~:text=%E5%BF%85%E9%A1%BB%E8%A6%81%E4%BA%86%E8%A7%A3,%E8%83%BD%E6%AD%A3%E7%A1%AE%E5%A3%B0%E6%98%8E%E3%80%82

  4. Birkett, A. (2019). Form Design: 13 Empirically Backed Best Practices | CXL. Retrieved 26 February 2021, from https://cxl.com/blog/form-design-best-practices/

  5. ARIA Landmark Roles. (2021). Retrieved 26 February 2021, from https://www.washington.edu/accessibility/web/landmarks/

  6. 表格标签. (2021). Retrieved 26 February 2021, from https://wangdoc.com/html/table.html

  7. 表单标签. (2021). Retrieved 26 February 2021, from https://wangdoc.com/html/form.html

转发备注出处, thanks~

前端手札
web

本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议 ，转载请注明出处！