裁纸刀下 » HTML http://ofcss.com 独立 自由 诚信 宽容 责任 平常心 Fri, 20 Apr 2012 04:08:47 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 对《优化浏览器渲染》的补充【译】 http://ofcss.com/2011/03/14/browser-rendering-optimizer-translation-extra.html http://ofcss.com/2011/03/14/browser-rendering-optimizer-translation-extra.html#comments Mon, 14 Mar 2011 08:06:50 +0000 小李刀刀 http://ofcss.com/2011/03/14/browser-rendering-optimizer-translation-extra.html ISD Webteam的大布同学（twitter：@tc_bryanzhang）在2010年1月翻译了google Page Speed系列中的Optimize browser rendering，很是方便了大家。在此基础上，google又有了更新，我且在此把google新增的部分翻译一下，作为对大布同学译稿的补充。

google这篇文章关注的是资源被下载到客户端以后，在浏览器加载、解释、渲染HTML、CSS和JavaScript阶段的性能优化，提出了5个要点：

  1. 使用高效率的CSS选择器
  2. 避免CSS expressions
  3. 将样式表放在页面顶部
  4. 指定图像尺寸
  5. 尽早指定文档的字符编码

前四点大布同学已经翻译过了，没拜读过的同学可以点击上面的链接到涛哥的博客学习，第五点的翻译如下：

概述

为HTML文档尽早指定字符编码，可以让浏览器立刻开始执行脚本。

细节

HTML文档是作为带有字符编码信息的字节流序列在互联网中传送的。字符编码信息可以在随文档发送的HTTP响应头信息中指定，也可以在文档的HTML标签中指定。浏览器根据字符编码信息将字节流转换为显示在浏览器上的字符。如果不知道如何构造一个页面的字符，浏览器自然也不能正确地渲染页面。绝大部分浏览器在开始执行任何JavaScript代码或者绘制页面之前都要缓冲一定数量的字节流，缓冲的同时它们也要查找相关的字符编码设定（一个值得注意的例外是IE6/7/8）。

不同浏览器需要缓冲的字节流数量不同，另外如果找不到编码设定，各浏览器默认的编码也不同。但是不管哪一种浏览器，如果在已经缓冲了足够的字节流、开始渲染页面之后才发现指定的编码设定与其默认值不同，都会导致重新解析文档并重绘页面。如果编码的变化影响到了外部资源（例如css\js\media），浏览器甚至会重新对资源进行请求。

为了避免这些延迟，对任何超过1k（精确地说是1024字节，这是我们测试过的所有浏览器的最大缓冲限制）的HTML文档，要尽早指定字符编码。

建议

通过HTTP头信息或meta标签指定编码

为HTML文档指定编码设定有几种方式：
服务器端：通过web服务器的配置来指定编码参数，为所有text/html类型的文档指定带有正确编码信息的Content-Type头信息。例如 Content-Type: text/html;charset=UTF-8
客户端：在HTML代码中包含http-equiv="content-type"的meta标签，并指定字符编码。例如 。

如果可能的话，为你的web服务器做指定字符编码的HTTP头信息配置。某些浏览器（例如Firefox）在执行JavaScript之前会用（比其它浏览器）更短的延迟缓冲来检查头信息中是否指定字符编码。这意味着它们可以跳过对HTML标签的检查，缩短缓冲的字节数和延迟时间。

把meta标签放在head区域的最前面

如果你不能对web服务器配置进行修改，又需要通过meta标签指定编码，要确保你用于指定编码的meta标签是文档中head标签的第一个子元素。浏览器会在文档的前1024字节中寻找字符编码参数，因此为了避免性能损耗，编码参数在文档头部越早出现越好（译注：在IE6以下的版本中，特定情况下，如果该meta标签不是head的第一个子元素，则会被忽略。具体触发情况尚未进行仔细测试，初步估计是与web服务器配置的默认编码或浏览器默认编码有关）。

始终指定文档类型

在浏览器开始检查字符编码设定前，它们必须先检测将被处理的文档是什么类型。如果没有在头信息或meta标签中指定文档类型（content-type），浏览器就会通过很复杂的算法去“嗅探”文档的类型。这个过程会造成额外的延迟，而且还会带来安全漏洞。

务必指定正确的字符编码

你在HTTP头信息或meta标签中指定的字符编码设置一定要和编辑HTML文档时的实际字符编码一致，这非常重要。另外，如果同时通过HTTP头信息和Meta标签两种方式指定了字符编码，它们一定要保持一致。否则浏览器发现两者相互矛盾，会造成页面渲染错误或者为了重绘页面而造成额外的延迟。有关这一点，你可以阅读HTML 4.01规范（英文）中的5.2节：字符编码（英文）。

扩展阅读

如果需要进一步了解content-type以及字符编码设定存在/缺少的不同情况下浏览器行为的细节，可以参阅以下资料（英文）：

相关日志

]]> http://ofcss.com/2011/03/14/browser-rendering-optimizer-translation-extra.html/feed 2 HTML验证的价值探讨【译】 http://ofcss.com/2010/10/22/the-value-of-html-validation-translation.html http://ofcss.com/2010/10/22/the-value-of-html-validation-translation.html#comments Fri, 22 Oct 2010 08:47:01 +0000 小李刀刀 http://ofcss.com/2010/10/22/the-value-of-html-validation-translation.html 作者：

原文：http://www.nczonline.net/blog/2010/08/17/the-value-of-html-validation/

这篇文章我已经酝酿了很久，期间还拜读了 关于 Remy Sharp’s site 的这篇大作。我和Chris曾就这个话题多次交换意见，最终我们彼此的观点都有所改变，接受了一些过去无法接受的意见。我曾经在公开的、私下的各种场合直言不讳地表示过，目前的HTML验证状况对我来说纯粹是浮云。要了解我的看法，你需要先明白HTML验证到底是什么。

 

什么是HTML验证

是对你的网页代码执行一系列验证任务，主要包括：

  1. 代码语法验证 – 检查语法错误。从技术上说，尽管 <foo> 不是HTML规范中的一个标签，<foo bar="baz"> 在语法上也是正确的，所以语法验证唯一的作用就是确保编写出合法的HTML代码。
  2. 标签嵌套验证 – 检查标签是否正确地按照打开的先后顺序关闭。比如一个<div>标签没有被正确关闭的话，在这项检查中就会报错。
  3. DTD定义验证 – 检查你的代码是否遵循了指定的DTD的定义。这项验证检查的内容包括标签名称、属性名称、以及标签包含关系（某个标签是否允许被嵌套在另一个内部）。
  4. 异常实体验证* – 检查是否存在DTD规范中不曾提及的任何东西。通常自定义标签和自定义属性就会在这一项验证中报错。 （*译者注：关于原文中的Outlier Validation，指的是对不属于DTD定义范围内的实体的验证。在数学上，把这种游离于基准之外的值成为离群值，因而在数学上有Outlier Validation – 离群验证的概念。但是在HTML中，对于DTD中的元素、属性，均是实体，这项验证要做的是找出不在定义范围内的异常实体，因此暂译为“异常实体验证”，若您有更好的翻译方案，欢迎探讨。）

请记住：以上这四项验证任务只是为了便于理解而进行的逻辑划分，而不一定是验证器真正的实现方式。如果在某个验证任务上失败了，就说明HTML代码在该项对应的方面存在问题，是不符合规范的。

关于HTML验证的争论

HTML验证的支持者的主要观点是：HTML验证能够保证网页在不同浏览器下的互用性。不同核心的浏览器拥有不同的语法分析器以及HTML验证的具体实现。只有同时满足所有浏览器的要求，你的代码才能始终正常工作。由于每个浏览器在其语法分析器中各自以不同方式来实现纠错功能，因此对于不规范的代码，我们无法预计浏览器会如何呈现它。

而HTML验证的反对者则认为：HTML验证过于严格，而且没有考虑到浏览器的真实工作情况。HTML中的某些情况虽然从技术角度看可能是不合规范的，但是所有的浏览器都能按照相同的方式处理它们（注：并不总是相同的方式）。如果我自己能对自己编写的不规范代码负责，那我就不需要担心什么HTML验证——我真正关注的只是让这个网页正确呈现。

 

我的观点

我很少会就某个争论的问题公开表态，这恰好是其中之一，希望你喜欢。基于“HTML验证过份严格，不符合实际工作场景”的原因，我一直都属于反对HTML验证的阵营。有一些被浏览器广泛支持的东西（<head>里面的<noscript>，</html>之后的<script>）居然也不符合规范，而为了得到正确的用户体验，它们有时候却是必不可少的。

总的来说，HTML验证给我造成的麻烦主要集中在第四项（异常实体验证）。我喜欢在HTML中用自定义属性为特定元素提供额外元数据，而且坚持这种做法。对我来说，要为某个元素提供关联数据时，只需给它增加一个相应的属性。某些人某种时候使用一个合法的属性的目的纯粹是为了让代码能够通过验证，哪怕这个属性根本不是设计来在这种情况下用的。我绝不认同这种做法。

浏览器有个恶心的小秘密，那就是它们根本不会按照DTD文档定义去做HTML验证。你加在网页顶部的文档类型（doctype）只是让语法分析器切换到某种指定的工作模式，但是没有任何一种工作模式会去下载该文档类型的DTD然后验证代码是否符合DTD规定。这是什么意思呢？这就是说，浏览器只是用一个简单的语法分析器来处理HTML，而这个简单的语法分析器只包含一些关于自关闭标签、块元素对行内元素的指定异常而已（我相信其它情况也是如此）。

就自定义属性而言，所有的浏览器都会把它们当作正确的属性一样处理，并因此使得JavaScript可以通过DOM对它们进行操作。浏览器不仅在分析自定义属性的时候不报错，而且在处理阶段也会像把它们当作正常的属性来处理！那么，即使这些自定义属性不能通过HTML验证，我们又何须在意呢？我还会继续使用自定义属性，而且我们都看到HTML5已经正式把自定义属性作为数据集了，哥很欣慰。

还有个很好的例子：是一项却极其重要的技术，但是按照验证器的检查结果，ARIA却是不规范的HTML。ARIA 技术是在HTML4的基础上添加自定义属性实现的。这些元素为HTML元素提供额外的语义，浏览器能够把这些语义传递给专为不健全人士设计的辅助设备，帮助他们更方便地使用web。当今所有的主流浏览器都支持 ARIA 标签，然而如果你在网页里添加这些属性，你的网页就不能通过HTML验证了。

此外还有被当作错误修正的一部分而被抛弃的自定义标签。我对此没有很强烈的体会，但是个人而言，我觉得如果语义正确的话，在页面中使用自定义标签应该是可以的，只是目前未知我还没有遇到这方面的很好的案例。

再明确一下我的立场：我坚决认同HTML验证的第一项（译注：代码语法验证）和第二项（译注：标签嵌套验证）是很基础、很重要的，应该进行验证并确保通过。第三项（译注：DTD定义验证）也还算重要但是不如前两项。第四项（译注：异常实体验证）的重要性我是不认可的，因为它涉及到自定义属性的使用。异常实体验证顶多只能标记为警告级别，以提醒我们做二次检查看是不是拼错了属性名称。把自定义标签标记为错误或许是个好主意，但是会有一些不利影响——因为它关系到一些其它内容的嵌入标签，例如SVG和MathML(本质上，这些每一种情况都需要成为解析器里的一种特殊异常)。

 

为了验证而验证？

我要以最强烈的方式表达这个观点：为了验证而验证纯属有病！规范的HTML意味着通过了全部四项检查，但是还有很多东西是仅靠“规范的HTML”不能保证的：

  • 规范的HTML不能保证可用性
  • 规范的HTML不能保证良好的用户体验
  • 规范的HTML不能保证网站功能正常运作
  • 规范的HTML不能保证正确的布局

拥有规范的HTML代码或许可以看作一枚荣誉勋章，带给你病态的满足感。但是它本身不是一种成功，更不是衡量成功与否的标准。你的（通过验证的）代码实际运行起来未必比我的（未通过验证的）代码效果更好。

 

HTML5 验证

HTML5验证修正了我和其他人在HTML4验证中遇到的一些问题。它明确地支持ARIA属性，你也可以添加自定义属性，只要它们以“data-”开头即可。这些情况在HTML5中都被认为是合乎规范的。与HTML4验证相比，这令我满意。要声明的一点是，HTML5验证器中仍有一些我不赞成的部分。尽管如此，我还是认为HTML5验证器比HTML4验证器更好地反映了实际的工作用例。

 

学术问题，文明探讨

我确实认为HTML验证服务中的某些部分是非常有用的，但是我不想被它挟持，因为我要用自定义属性。我在日常工作中很自豪地使用着ARIA规则，并且根本不在乎它们会让HTML4验证器不爽。再说一次：验证器总共有四个任务，只有一个让我不爽，而HTML5验证器注意到了我的需求。

我知道我谈论的是一个热点问题，它将会引出更多的帖子和博文。我已经在评论表单前做了免责声明，但还是要提醒大家在今后的讨论中保持文明，提供建设性的意见。我还知道双方接下来肯定会有非常强烈的争论并且每个人都会有各自的重点（作者注：我没有刻意押韵；译者注：我也没有刻意押韵）。在评论中出现良性的、强烈的辩论非常好，但让我们都约束一下自己的火爆脾气。这是一个知识性的辩论，不是一个感性的辩论。我要声明，我会比以往更加严格地审核评论 —— 所以希望大家都规矩点。

免责声明：本文所表达的任何观点和看法都仅代表 Nicholas C. Zakas 个人，与 Yahoo！，Wrox 出版社，O’Reilly 出版社 无关，与其它任何人无关。我仅代表我自己，不代表他们。

你可以在我的站点留言，或者从你自己的站点发送 trackback。

相关日志

]]> http://ofcss.com/2010/10/22/the-value-of-html-validation-translation.html/feed 1 最近的书单 http://ofcss.com/2010/06/09/my-rencent-booklist.html http://ofcss.com/2010/06/09/my-rencent-booklist.html#comments Wed, 09 Jun 2010 10:44:08 +0000 小李刀刀 http://wukangrui.com/2010/06/09/my-rencent-booklist.html 好久没看书了，一直以来喜欢睡觉前、如厕时看点书，于是前几天到学校图书馆翻了翻，还算不错，虽然没有什么新书，但是翻出一堆可以看看的书。简单列一下：

《重构HTML——改善Web应用的设计》：来自Adobe的一本关于网页重构的书，这本书虽然是讲如何对编写混乱的HTML代码进行重构的书，但是其中的很多东西其实对于加深对web标准化、语义化的理解很有帮助。其中的很多章节也都是HTML结构设计的很好的实践。这本书没多少深度，基本上对于在标准化、语义化方面有一定基础的读者帮助不大。

《CSS终极参考手册》：这本书可以当作《CSS权威指南》的补充读物，涵盖了CSS2.1和CSS3已实现的特性。主要优点在于对每个知识点的讲解都比较注重实用性，而且其中对不同浏览器厂商的特有属性以及浏览器兼容性问题有较细致的说明。即使是很熟练的网页重构人员，偶尔翻翻还是会有收益的。

《高性能网站建设指南》：这本书实际上是对yahoo关于改善网站性能的34条建议（或者说34个最佳实践）的细致阐述。如果光看了网上的雅虎34条之后觉得还需要更详细的讲解，可以看看这本书。

《JavaScript DOM编程艺术》：这本书不适合于前端开发工程师，但是比较适合以前只做网页重构的人员学习JavaScript。如果你的JavaScript基础不好，或者是初次接触JavaScript，主要用于操作DOM树，那么倒是值得一看。如果你本来已经很熟悉JavaScript，有较丰富的Ajax实践了，那么这本书对你基本上没有价值。

《JavaScript设计模式》：这本书可以算是这次列出的书单里最有深度的一本，适合初、中级前端开发人员阅读。其中对JavaScript的面向对象特征，各种设计模式在JavaScript中的实现做了深入讲解。这本书中对“接口”、“继承”、“方法的链式调用”等概念的讲解，绝对能引起web前端开发工程师的兴趣。如果你是从其它编程语言转到JavaScript，或者以前从来没有接触过JavaScript中的这些高级概念，绝对值得一读。

相关日志

]]> http://ofcss.com/2010/06/09/my-rencent-booklist.html/feed 0