是时候再提web标准

是时候再提web标准

2016/07/06 · 基础技术 · WEB

原文出处: 灵感(@灵感_idea )   

前端编码规范(2)HTML 规范,前端编码

**背景**

**web标准是个老生常谈的话题。引入国内的时间,粗略算下来,有十年左右了。但是由于国内前端优秀人才的缺失和相关教育跟进的缓慢,造成了很多人都没有对它引起足够的重视并运用到自己的实际项目当中,同时又花了较多精力在眼花缭乱的新技术方案和工具中,这就造成了技术断层,影响不是一个两个人,而是一大部分,如果再缺少相关的正确引导,就会保留很多不正确的编码习惯,对于个人成长和所做的项目都是不利的。**

为什么是时候再提呢?可以先来看看下面一张具有一定代表性的图,截自我的企鹅群(152128548)

图片 1

1、标签仍在被滥用
2、重视觉,轻语义和结构
3、热衷于跟进热门新技术,不重视基础
4、当我在跟大家说重视基础的时候,要么有人说原生js,要么有人说css原理和技巧,没人说html

由于以上的几点,加上各种场合和会议似乎很少提及这些方面的东西,新手在被老手“牵”着走,老手的精力又不在这些比较基础的东西上。这篇文呢,就是跟大家一起回到起点,去看看怎样做才算是符合了web标准的编码。

文档类型

推荐使用 HTML5 的文档类型申明: <!DOCTYPE html>

(建议使用 text/html 格式的 HTML。避免使用 XHTML。XHTML 以及它的属性,比如 application/xhtml xml 在浏览器中的应用支持与优化空间都十分有限)。

HTML 中最好不要将无内容元素 [1]的标签闭合,例如:使用 <br> 而非 <br />.


问题来源

HTML 验证

一般情况下,建议使用能通过标准规范验证的 HTML 代码,除非在性能优化和控制文件大小上不得不做出让步。

使用诸如 W3C HTML validator 这样的工具来进行检测。

规范化的 HTML 是显现技术要求与局限的显著质量基线,它促进了 HTML 被更好地运用。

不推荐

 

  1. <title>Test</title>
  2. <article>This is only a test.

推荐

 

  1. <!DOCTYPE html>
  2. <meta charset="utf-8">
  3. <title>Test</title>
  4. <article>This is only a test.</article>

1、门槛低、简单

一周就可以掌握html,常用标签不多,用不到的不用管

比如:h1~6、p、span、div、img、a、input等,我们来随意的看一张截图

图片 2

上面是某宝PC端的登录页,可能是由于种种原因(不详),只用了少量的标签,所以,并不说它是不好的或者是错的,但它是其他很多人的写照。如果我说html标签有100多个,你会是什么反应?

1、不知道,没想到有这么多
2、知道,但认为很多都用不上

你会是哪种?

如何在合适的时候,合适的地方,使用正确的标签,这是web标准的基本要求。后面细说。

CSS很简单,常用属性也就那么多

宽、高、边框、背景、定位、浮动、边距,如果你掌握了这么多,那么就能够应对很多页面布局的情况了。如果你因此就认为css很简单,那么就等着它来“惩罚”你吧。

不好的方面:各种兼容问题,各种奇葩布局要求,各种不可预知的bug

好的方面:诸多奇妙的技巧和css3新属性,能够帮助我们做出充满美感又神奇的效果

如果你依然觉得CSS太简单,那么请看一下这里https://drafts.csswg.org/indexes/,要坚强~

省略可选标签

HTML5 规范中规定了 HTML 标签是可以省略的。但从可读性来说,在开发的源文件中最好不要这样做,因为省略标签可能会导致一些问题。

省略一些可选的标签确实使得页面大小减少,这很有用,尤其是对于一些大型网站来说。为了达到这一目的,我们可以在开发后期对页面进行压缩处理,在这个环节中这些可选的标签完全就可以省略掉了。


2、只需要做“对”,不需要做好

很多时候,即使写错了浏览器会包容它,当我们的代码是不规范的,甚至有时候是错的,但是浏览器仍然将它“正常”显示出来,这个时候,我们意识不到自己的错误。认为看起来没问题就没问题,这是很危险的。

标签不用在意,交给CSS去处理就好,理论上,我们可以通过一定的CSS规则,任意的改变一个元素的表现,这就造成了对html标签的不重视,因为我们总能让它们看起来没有任何问题。

脚本加载

出于性能考虑,脚本异步加载很关键。一段脚本放置在 <head> 内,比如 <script src="main.js"></script>,其加载会一直阻塞 DOM 解析,直至它完全地加载和执行完毕。这会造成页面显示的延迟。特别是一些重量级的脚本,对用户体验来说那真是一个巨大的影响。

异步加载脚本可缓解这种性能影响。如果只需兼容 IE10 ,可将 HTML5 的 async 属性加至脚本中,它可防止阻塞 DOM 的解析,甚至你可以将脚本引用写在 <head> 里也没有影响。

如需兼容老旧的浏览器,实践表明可使用用来动态注入脚本的脚本加载器。你可以考虑 yepnope 或 labjs。注入脚本的一个问题是:一直要等到 CSS 对象文档已就绪,它们才开始加载(短暂地在 CSS 加载完毕之后),这就对需要及时触发的 JS 造成了一定的延迟,这多多少少也影响了用户体验吧。

终上所述,兼容老旧浏览器(IE9-)时,应该遵循以下最佳实践。

脚本引用写在 body 结束标签之前,并带上 async 属性。这虽然在老旧浏览器中不会异步加载脚本,但它只阻塞了 body 结束标签之前的 DOM 解析,这就大大降低了其阻塞影响。而在现代浏览器中,脚本将在 DOM 解析器发现 body 尾部的 script 标签才进行加载,此时加载属于异步加载,不会阻塞 CSSOM(但其执行仍发生在 CSSOM 之后)。

所有浏览器中,推荐

 

  1. <html>
  2.   <head>
  3.     <link rel="stylesheet" href="main.css">
  4.   </head>
  5.   <body>
  6.     <!-- body goes here -->
    1.     <script src="main.js" async></script>
  7.   </body>
  8. </html>

只在现代浏览器中,推荐

 

  1. <html>
  2.   <head>
  3.     <link rel="stylesheet" href="main.css">
  4.     <script src="main.js" async></script>
  5.   </head>
  6.   <body>
  7.     <!-- body goes here -->
  8.   </body>
  9. </html>

3、热衷于“向前看”

学习新技术,丰富自己的技能树——html5、canvas、svg、react、ES6等。

解决“难题”——觉得一般的工作没什么挑战了,所以不屑于去深挖自己已经会了东西。

做出炫酷的效果——纯CSS图标、动画,3D动画,canvas动画等。

跟风式学习——大家都在谈,业界都在捧,看起来很好的东西,就开始躁动不安,跃跃欲试,其实有句话叫做:“基础不牢,地动山摇”,兴致冲冲的去学习新的东西的时候,往往会发现,没有足够的基础,是很难前行的。

上面说的这些是错的么?当然都对,特别是在技术发展更新迭代速度快的互联网领域,想会得更多让自己更强,同时会的更多在实际应用中可选择的方案也更多,兴趣驱动去学习,这是好事,我自己也是这样的,但我们需要注意的是,学习不是一条直线,不能沿着一条线一直往前冲,除了长度,还有深度,需要我们不断的从各个方面去打磨和填充才能日臻完善。

语义化

根据元素(有时被错误地称作“标签”)其被创造出来时的初始意义来使用它。打个比方,用 heading 元素来定义头部标题,p 元素来定义文字段落,用 a 元素来定义链接锚点,等等。

有根据有目的地使用 HTML 元素,对于可访问性、代码重用、代码效率来说意义重大。


文档结构和意义为先

我们都知道,实现一种效果可以有多种方式,那么哪种才是最优的?来看例子

多媒体回溯

对页面上的媒体而言,像图片、视频、canvas 动画等,要确保其有可替代的接入接口。图片文件我们可采用有意义的备选文本(alt),视频和音频文件我们可以为其加上说明文字或字幕。

提供可替代内容对可用性来说十分重要。试想,一位盲人用户如何能知晓一张图片是什么,要是没有 @alt 的话。

(图片的 alt 属性是可不填写内容的,纯装饰性的图片就可用这么做:alt="图片 3")。

 

  1. <img src="luke-skywalker.jpg" alt="Luke skywalker riding an alien horse">

列表

什么特点呢?最明显的就是有很多项,项和项之间相互独立,竖着排列,像这样

我是列表
我是列表
我是列表

它可以被怎样写呢?

1、

XHTML

我是列表<br> 我是列表<br> 我是列表<br>

1
2
3
我是列表<br>
我是列表<br>
我是列表<br>

2、

XHTML

<li>我是列表</li> <li>我是列表</li> <li>我是列表</li>

1
2
3
<li>我是列表</li>
<li>我是列表</li>
<li>我是列表</li>

3、

XHTML

<ul> <li>我是列表</li> <li>我是列表</li> <li>我是列表</li> </ul>

1
2
3
4
5
<ul>
    <li>我是列表</li>
    <li>我是列表</li>
    <li>我是列表</li>
</ul>

上面三种是比较直接想到的对的写法,当然也可以用ol,算同一种方法。它们所能实现的效果是类似的,往往我们会从表现的角度考虑说第一种不够灵活,无法控制样式,第二种方法浏览器也不会不搭理你,它会把li解析成块级元素,让它们单独排列,但它失去了告诉浏览器“我是个列表”的标志,也就是外层容器(ul/ol),最好的写法肯定是第三种,它不仅看上去是对的,还告诉浏览器这是个列表,还有列表所应有的特点,比如“缩进”和“着重号”,当然,最大的益处仍然是它是有意义的,也是为什么这里没有提div和p等元素的原因。

关注点分离

理解 web 中如何和为何区分不同的关注点,这很重要。这里的关注点主要指的是:信息(HTML 结构)、外观(CSS)和行为(JavaScript)。为了使它们成为可维护的干净整洁的代码,我们要尽可能的将它们分离开来。

严格地保证结构、表现、行为三者分离,并尽量使三者之间没有太多的交互和联系。

就是说,尽量在文档和模板中只包含结构性的 HTML;而将所有表现代码,移入样式表中;将所有动作行为,移入脚本之中。

在此之外,为使得它们之间的联系尽可能的小,在文档和模板中也尽量少地引入样式和脚本文件。

清晰的分层意味着:

  • 不使用超过一到两张样式表(i.e. main.css, vendor.css)
  • 不使用超过一到两个脚本(学会用合并脚本)
  • 不使用行内样式(<style>.no-good {}</style>
  • 不在元素上使用 style 属性(<hr>
  • <link rel="stylesheet" href="main.css" type="text/css">
  • <script src="main.js" type="text/javascript"></script>
  • 推荐

     

    1. <link rel="stylesheet" href="main.css">
    2. <script src="main.js"></script>

    可用性

    如果 HTML5 语义化标签使用得当,许多可用性问题已经引刃而解。ARIA 规则在一些语义化的元素上可为其添上默认的可用性角色属性,使用得当的话已使网站的可用性大部分成立。假如你使用 navasidemainfooter 等元素,ARIA 规则会在其上应用一些关联的默认值。
    更多细节可参考 ARIA specification

    另外一些角色属性则能够用来呈现更多可用性情景(i.e. role="tab")。


    Tab Index 在可用性上的运用

    检查文档中的 tab 切换顺序并传值给元素上的 tabindex,这可以依据元素的重要性来重新排列其 tab 切换顺序。你可以设置 tabindex="-1" 在任何元素上来禁用其 tab 切换。

    当你在一个默认不可聚焦的元素上增加了功能,你应该总是为其加上 tabindex 属性使其变为可聚焦状态,而且这也会激活其 CSS 的伪类 :focus。选择合适的 tabindex 值,或是直接使用 tabindex="0" 将元素们组织成同一 tab 顺序水平,并强制干预其自然阅读顺序。


    ID 和锚点

    通常一个比较好的做法是将页面内所有的头部标题元素都加上 ID. 这样做,页面 URL 的 hash 中带上对应的 ID 名称,即形成描点,方便跳转至对应元素所处位置。

    打个比方,当你在浏览器中输入 URL http://your-site.com/about#best-practices,浏览器将定位至以下 H3 上。

     

    1. <h3 id="best-practices">Best practices</h3>

    格式化规则

    在每一个块状元素,列表元素和表格元素后,加上一新空白行,并对其子孙元素进行缩进。内联元素写在一行内,块状元素还有列表和表格要另起一行。

    (如果由于换行的空格引发了不可预计的问题,那将所有元素并入一行也是可以接受的,格式警告总好过错误警告)。

     

    1. <blockquote>
    2.   <p><em>Space</em>, the final frontier.</p>
    3. </blockquote>
      1. <ul>
    4.   <li>Moe</li>
    5.   <li>Larry</li>
    6.   <li>Curly</li>
    7. </ul>
      1. <table>
    8.   <thead>
    9.     <tr>
    10.       <th scope="col">Income</th>
    11.       <th scope="col">Taxes</th>
    12.     </tr>
    13.   </thead>
    14.   <tbody>
    15.     <tr>
    16.       <td>$ 5.00</td>
    17.       <td>$ 4.50</td>
    18.     </tr>
    19.   </tbody>
    20. </table>

    HTML 引号

    使用双引号(“”) 而不是单引号(”) 。

    不推荐

     

    1. <div class='news-article'></div>

    推荐

     

    1. <div class="news-article"></div>

    [1]: 此处的空白元素指的是以下元素:areabasebrcolcommandembedhrimginputkeygenlinkmetaparamsourcetrackwbr

    http://www.bkjia.com/Javascript/1299551.htmlwww.bkjia.comtruehttp://www.bkjia.com/Javascript/1299551.htmlTechArticle前端编码规范(2)HTML 规范,前端编码 文档类型 推荐使用 HTML5 的文档类型申明: !DOCTYPE html (建议使用 text/html 格式的 HTML。避免使用 X...

标题

作为标题,特点也简单,比页面上其他的文本更大、更粗。
我们可以这样写:

1、

XHTML

<span class="head">我是标题</span>

1
<span class="head">我是标题</span>

2、

XHTML

<p><b>我是标题</b></p>

1
<p><b>我是标题</b></p>

3、

XHTML

<h1>我是标题</h1>

1
<h1>我是标题</h1>

不看代码的情况下,三者可以一模一样,但看了代码的话,大家应该都会第三种写法是最好的,第三种写法的好处有哪些?

1、本身是块级元素
2、是独特的,不像p或者span等元素会用到页面当中的很多地方
3、更加重要的是,在不加任何css规则的情况下,标题元素仍然明显是个标题,页面的无样式视图将显示其预期的文档结构,正确的标题元素传递了“意义”而不只是表现指令
4、屏幕阅读器、手机和其他浏览器也将知道如何处理标题元素
5、搜索引擎友好,除了title和meta,标题是最可能存在关键字的地方,利用好它,会更加方便用户找到你的页面

但是它有没有问题困扰着我们呢,答案是有,h1和h2这些标题的默认样式被认为过于粗大,这会让有些人倾向于使用更高级别的标题元素,其实这个大家都知道,不是大问题,可以用css来控制,前提是:先结构,后表现。至于选择使用h几,也不是没有讲究的,它们既然是分了级别,那自然是有一定意义所在,一般来说,h1是个重要的标识,页面当中有一个就好,然后,不要出现类似h2包裹h1的情况。

表格

现在如果提到表格(table),很多人会觉得好笑,使用web标准构建网站的一个最荒诞的说法就是你应该永远不使用表格。

是的,使用table来布局确实是有劣势,但并不代表我们不能用表格来做适合它做的事,比如:数据化表格。

最简单的表格可以有下面这个结构:

XHTML

<table> <tr><td></td><td></td></tr> <tr><td></td><td></td></tr> <tr><td></td><td></td></tr> </table>

1
2
3
4
5
<table>
    <tr><td></td><td></td></tr>
    <tr><td></td><td></td></tr>
    <tr><td></td><td></td></tr>
</table>

有时候,我们会在表格的上方加一点说明性文字,通常我们会习惯性的使用h*或者p标签来包裹这一段内容,如果你是用div,那么…

其实我们有更好的选择——<caption>,这个是表格自己的专有标题哦,有它为什么我们还要用别的呢?

除此之外,如果我们想给表格的第一行算作表头,可以怎么做呢?可以这样:

XHTML

<tr><th></th><th></th><th></th></tr>

1
<tr><th></th><th></th><th></th></tr>

把这行代码放在第一行,th标签会给它不同于td的样式来区分出和其他行的不同,此外它可以是行的,也可以是列的,怎么区分呢?还有这个——scope属性scope=row/col,把此属性添加到th标签中即可设置它的归属。

但这样就够了吗,如果对于简单的表格来说已经挺好,那么好像它还没有比较清晰的逻辑结构,那么,不卖关子了。较完整的表格,应该是下面这样:

XHTML

<table summary="这是一个表格的内容简介" cellspacing="0"> <caption>表格标题</caption> <thead> <tr> <th scope="col" id="name">姓名</th> <th scope="col" id="address">地址</th> <th scope="col" id="databirthday">出生日期</th> </tr> </thead> <tbody> <tr> <td>ewee<td> <td>hubei<td> <td>19870102<td> </tr> <tr> <td>rewe<td> <td>wuhan<td> <td>419880103<td> </tr> <tr> <td>ertww<td> <td>yichang<td> <td>19870205<td> </tr> <tbody> <tfoot><tr><td>one</td><td>two</td><td>three</td></tr></tfoot> </table>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<table summary="这是一个表格的内容简介" cellspacing="0">
    <caption>表格标题</caption>
        <thead>
            <tr> <th scope="col" id="name">姓名</th> <th scope="col" id="address">地址</th> <th scope="col" id="databirthday">出生日期</th>
            </tr>
        </thead>
        <tbody>
            <tr> <td>ewee<td> <td>hubei<td> <td>19870102<td>
            </tr>
            <tr> <td>rewe<td> <td>wuhan<td> <td>419880103<td>
            </tr>
            <tr> <td>ertww<td> <td>yichang<td> <td>19870205<td>
            </tr>
    <tbody>
    <tfoot><tr><td>one</td><td>two</td><td>three</td></tr></tfoot>
</table>

是不是顿觉十分的清晰,慢着,summary=”这是一个表格的内容简介”这句是什么鬼?好吧,看内容便知,它是关于表格的一个简介,这个简介用户是看不到的,屏幕阅读器可以利用该属性。

<strong><em><b><i>和其他短语元素

短语元素,在于控制的颗粒更小,无关布局,和表现也没有太大关系(虽然它会有加粗或者倾斜的效果),用来对于页面中的某些特殊内容做出特别的标识,比如“强调”、“引用”等。

那么它们的区别在哪儿?

<strong>代替<b>,<em>代替<i>

传达意义和结构,而不是给出表现指令。

<em>表示强调,<strong>表示更加强调,在语音合成器用户代理场景下,它们还表现为音量、音调及语速的区别。如果一个元素需要既强调又斜体,那么我们可以选择正确的标签,然后通过样式来控制其他方面。

如此之外还有其他短语元素,比如:

<cite> 包含对其他来源的引言或引用
<code> 指定一个计算机代码片段
<var> 表示一个变量或者程序参数实例

最小化标示

通常情况下,较少的代码意味着更快的下载,还意味着更少的服务器空间和带宽消耗。有个问题就是,即使你写出了符合web标准的页面仍然不能说明你写出了足够简洁或者合理的代码。正所谓规则是死的,容易做到,碰到实际场景,不同的做法会导致结果不同。在我们成长过程中,会遇到不同的老师,要么是一篇文章,要么是一本书,要么是具体的某个人,追溯到最后仍然是人,不同的人,观点和习惯可能不同。比如,你可能会养成一个习惯就是希望给所有单独添加样式的元素分配一个类,这样做到了较强的可控性,但是,这样引发什么潜在的问题呢?

1、过多的类
2、类的命名难

除了上面两点,还有一个可能碰到的就是类名重复,然后样式冲突。

可能上面的问题你都遇到过,或许也想了办法去命名,去避免冲突,但有没有想过前因后果的关系?我们常常会“遇到问题”——“解决问题”,其实我们是在“制造问题”——“解决问题”。从现实情况看,也没有多少人在尝试的去打破它。

我认为,为什么要命名那么多的类,因为我们可以通过给予不同的类名去区别开来元素样式,即使有个类名叫info,我们可以起个a-info、b-info,那么它们俩就是不同的了,我们还可以.a.info、.b.info,同样能够对其进行区分,再向上追溯,我们为什么要使用类名来区分它们?最大的可能就是,我们在同一个父容器里,使用了较多同类型的子元素或者后代元素,这又是为什么呢?是不是回到了我们最初对于html标签的看法上——常用的标签不多?事实上,我们经常不加思索的使用div、p、span,一个用作大的包含块,一个用作包裹整段文字,span用来包裹行内文字,顶多再加上img、a、i等。我说的是不是很简单(然而这样还是会有人用错)。那么实际上有这么简单吗?正是因为“重视觉,轻语义”,至于我们能想起来使用的正确的,有意义的标签很少,觉得没有必要锱铢必较,那么网页中那么多的内容,难免会出现我们所说的那几个元素的重复,重复了怎么办?样式不同啊,加类,类多了怎么办?想办法区分类,于是,就是你所熟悉的那些行业问题了。

或许你会说,在大的、复杂项目里面,这些都是不可避免的,好,我同意你的说法,那如果我们能在结构和意义上做得更好,是不是能把这种情况大大改善?

其实我们的CSS选择器足够而且正在变得更加强大,我们完全没必要把希望都寄托在加类这个看起来很省劲的方法上

譬如:后代选择器、子选择器、各种伪类选择器、兄弟选择器、属性选择器等。

小结:任何做法都不要非白即黑,不偷懒,不含糊,把方法合理巧妙的结合起来才是正道!

本文由美洲杯在哪买球发布于计算机教程,转载请注明出处:是时候再提web标准

TAG标签:
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。