作为HTML4命令和标准的作者，伊恩 · 雅各布斯表示，在网络健康成长和逐步强大的同时，HTML标准也随之成熟并不断扩张自己的影响范围。“在过去的20年，网络已从一个动态文档的展现工具发展成为如今各种应用的共享平台。”
      雅各布斯指出，有两股力量推动着这次HTML标准革新。首先各种终端设备的不断出现，以及浏览器的繁复多样，大大增加了开发人员工作的复杂性，使得他们“随时随处”的工作方式难以继续。第二，网络世界与社交模式的结合，使得，只要你深入其中，就可以获得很多的客户–有时这一规模甚至可以达到成千上万。
      友好型标准
      业内一家主攻图形网站设计和营销的公司Ocupop，已经开始在他所有的业务中使用HTML5标准。
      Ocupop的一位网站开发人员兼使用性设计师马修·麦克维克指出，“这套标准下，并非所有推崇点都可以被称之为“新”。HTML标准之前作为技术使用典范，用来帮助开发者将试图达到的效果或者内容装载如浏览器中，对其实现进行有效的支持。例如，新标准里有一个用于地理定位的JS接口，移动设备上的浏览器可以自如读取GPS数据，而不再需要引入自定义API到相关硬件设备上。”
      这一改变对于终端用户来说可能并不明显，但对软件开发者而言却意义重大。地理信息对开发人员是完全透明的，开发人员不再需要花费精力去写针对不同浏览器和硬件设备的代码。所有这些，正是一套标准走向完备化所必需的。
      马修·麦克维克说：“同样，最新版本的CSS3允许开发者可以直接在浏览器内部实现图画效果，而这个版本之前则需要在外部使用PS制作再将其导入浏览器。比方，我们可以动态实现浏览器标题文字阴影化处理，而整个过程快速而简单。单这一环节就节省了大量的开发时间。”
      马修·麦克维克指出，浏览器各大厂商都渴望去尝试web的最新功能，而新的标准无疑成为这一过程的催化剂。厂商们也正努力让自己的研发能力与标准的更新节奏同步。
      HTML5中一个新特性“本地存储”允许客户端保留结构化的会话型数据。我们知道cookies技术只能在客户端保存很少量的数据且需要受到一些网络技术的限制。相比之下，“本地存储”使得数据存储量进一步扩大，甚至客户端与服务器端的连接不稳定或者无连接的情况下，也丝毫不影响存储性能。并且HTML5支持更加丰富的图形界面，比如，内嵌式的SVG，用户还可以使用基于栅格的布画用JS在网页内完成2D和3D图画效果。
      更严格的规范
      Google的一位软件工程师，伊恩·希克森非常赞同新的规范很大程度上帮助了厂商。希克森同时还是W3C和Web超文本应用技术工作组(WHATWG)的联络官。2004年希克森创建了这个补充性标准组织，由来自苹果，莫拉兹基金和Opera 的优秀技术人员组成。“我们对HTML最重大的贡献就是显著提高了标准的规范性”。“之前对规范的描述很模糊，各个浏览器厂商都认为自己遵守相同的规则和规范，但其实这些浏览器之间并不兼容。现在，对规范做了很多细节化处理，只要厂商严格按照规范来设计浏览器，那这些产品间会建立起良好的兼容性。当然，彻底实现这一切还需要大量的相关工作，但其重要性不容置疑。”
      即便与上一版本相比是个飞跃，HTML5也不会是完结篇，不同公司对这套新标准的诠释也不尽相同。对视频压缩技术、媒体流协议和数字版权加密技术，HTML5标准也没有做出统一阐述。2010年之前，各大浏览器制造商都统一使用Adobe Flash作为唯一的视频标准。随后苹果公司发表声明，iPhone和iPad将不再支持Flash技术，转而使用苹果自己的网络技术集，其中就包括HTML5。同时，微软和google也推出了自己的音视频解码器，导致的结果就是这两家的浏览器也不能完全兼容。所以，开发人员不得不提供多种网络技术来全面应对不同浏览器。
      卡内基梅陇大学计算机系教授张晖，作为资深的网络专家，认为“HTML5有强大的发展势头，但是迄今还不能百分之百支持所有的浏览器，原因在于它还是没有被广泛正式当做一个教科书般的标准。当然，浏览器厂商都在为此努力。而整个标准化的过程存在的挑战性不只针对视频解码，厂商们心里很清楚HTML5标准地位的确定会给他们自己和顾客带来巨大的好处，但与此同时为了使产品更具竞争力，商家力求创造更多的特色点于其中。”张晖提醒道“大家都想分得那块最大的蛋糕，但是如果过于贪婪，那么蛋糕最终会毁于一旦。”
      Conviva的产品主要集中于提高网络视频播放效果，而作为这家公司的创立者之一，张教授对视频解码技术的兴趣不言而喻。他认为视频是最复杂的网络载体信息，解码、媒体流协议和DRM的标准化道路无疑将会漫漫长久。
      来自官方消息称，一切顺利的话在2014年W3C将会把HTML5(限定为超文本标记语言规范)指定为推荐标准。但是伊恩 · 雅各布斯也指出：“由于其他独立规范的成熟度不同，这必然会导致他们最终标准化的时期不能达到同步。”
      W3C的一位交互领域专家菲利普·勒·加雷表示，“不能把HTML5简单看做是一个产品，当然我们永远不能说‘看，我完成了新的HTML”，“这套新规范包含了60个API，而且这个数量还在不断上升。例如，最近出现的一个新需求，希望浏览器能完成语音和文本之间的对话。我们会把这点加入到考虑范围中。”
      当谈到对HTML6的畅想，google的希克森说到：“Web尚无法有效支持的功能点可以说无穷尽，HTML就是HTML，去年开始我们就不再关注是5还是6这种问题了。像浏览器一样，HTML规范会不断完善和发展的，直到有一天我们不再使用他，那也是他要退出历史舞台的时刻了。”

【 精彩文章推荐 】

• 2010-10-31 -- JavaScript之继承方式 (1)
• 2011-02-22 -- 20款超赞的高品质滑块！ (3)
• 2010-11-17 -- 不让用户思考过多! (1)
• 2011-02-10 -- 2011年5大科技预言：平板电脑昙花一现 (2)
• 2010-10-30 -- JavaScript之修改对象 (0)
• 2011-04-30 -- HTML5之表单新功能详解 (5)
• 2010-10-29 -- JavaScript之定义类或对象六种方式 (1)
• 2010-11-26 -- JavaScript之事件处理(监听)函数 (0)

        首先我们需要收集数据，这儿主要有两个数据：页面加载时立即发送一个打点，称为PV打点；监听页面的beforeunload事件，在这个事件触发时再发送一个打点，称为unload打点。显然，如果丢失率为0或非常小的话，PV打点的数目和unload打点的数目应该相等或非常接近。即丢失率的计算公式为：丢失率=(PV-unload)/PV*100%

        如下图所示：

        按这个思路，我们在淘宝页面上进行了抽样埋点，并取得了足够多的PV及unload打点数据。但现实总是不完美的，整理这些数据的过程中，我们发现一些unload数据没有对应的PV数据，也就是说，由于各种各样的原因，不仅绑定beforeunload事件的unload打点有可能丢失，在页面初始化时发送的PV打点也可能丢失，尽管这个概率非常低。于是，我们又为打点添加了一个pvid参数，值为一个随机生成的字符串，每一组PV/unload打点的pvid都是相同的。这样，我们就能通过这个参数过滤出那些完整的PV/unload打点记录，再经过一些适当的整理，我们就得到了可以进行统计的有效数据。

        接下来，根据上面的公式，我们算出了beforeunload打点的总丢失率，约为20.81%，整个过程如下图所示：

        使用上面的方法我们连续统计了若干天的数据，发现beforeunload的总体丢失率维持在20%附近。接下来，我们再把这个数据按浏览器进行细分，看各个浏览器下这个丢失率是否有差异。

        首先看一下当前浏览器分布情况：

        清洗过的日志数据再根据UA字段细分后的结果为：

        从上图可以看到，各大浏览器的表现并不一样，其中份额占比最大的IE8在丢失率上表现最好，远低于总体平均水平，而chrome和safari却远高于平均值。各浏览器的丢失率乘以它们各自的权重（市场份额）之后再求和，就得到了总的平均丢失率，在我们的实验中，这个总丢失率约为20%。

        结论：使用beforeunload事件打点并不可靠，总丢失率在20%左右，其中各浏览器的表现各不相同；当然在一些丢失率要求不高的采集任务中这个事件还是能派上用场的，比如说统计页面停留时间、页面内容曝光比例等。

        最后需要特别说明的是：丢失率与用户浏览器分布情况、所采用的打点方式以及打点服务器响应速度等因素都有关，本结果仅供参考。

        统计人：鱼相、季札。

所谓第三方组件（widget），就是指我们提供给第三方网站使用的小模块，如微博的关注按钮，分享按钮，社交化组件，微博秀等等。当我们的组件放在第三方网站上时，不经意间会继承东道主网站的某些样式。但是，我们的目标是：保证自己组件样式的展现，即便寄人篱下，也不可丢失自己的个性！

通常我们会面临如下一些问题。

一、被同样的命名覆盖

我们先来看看某些网站的公用文件的写法：
eg1某网站：

clearfix这个命名，恐怕对于大多数的前端工程师都是再熟悉不过的了，这个词基本已经成为清除浮动某种方法的代名词了。当然，这种清除浮动的方法可以用其他命名，这个class也可以用来定其他属性。如果我们的组件恰好的也用了clearfix的命名，那么一定要想办法避免被同样命名的覆盖。在微博的组件中，我们会在所有组件中的class命名上加上我们自己特有的前缀WB_widget， 其余命名：WB_widget_xxxx;虽然看起来这样没有什么节省代码命名上的优势，但是确实可以避免一些简单的class命名重复。当然，如果您偏要修改我们组件的样式，偏偏要定义成和我们这样具有特殊命名的class同名的话，那我们也是拦不住的。

二、继承了多余的属性

再来看看下面几个网站的样式：
eg2某网站：

eg3某网站：

eg4某网站：

eg5某网站：

看着上面几个网站的通用写法，这就意味着，如果我们只是简单的定义，那么，我们的文本段落会有边距，我们的链接会有背景色，我们的图片都是块元素单独成一行，我们的文本区域都有着与第三方网站统一的边框，而不是我们定义的颜色……碰到这么多无法称之为样式显示bug的问题，一切都由于我们的组件规范的严谨性。那么如何保证网站对我们用的标签没有特殊定义？这个问题真正思考起来恐怕会得到一个很纠结的答案：除了考虑到我们经常用到的那些css属性之外，我们还要考虑到我们现在爱不释手的css3属性，既然考虑到了css3属性，不可避免的要考虑到各个高级浏览器的兼容问题。

纠结之后，恐怕最后得出的结论使我们非常不喜欢的reset周全考虑：

p { background:transparent;
 border:0;
 bottom:auto;
 clear:none;
 clip:auto;
 color:#333;
 cursor:auto;
 direction:ltr;
 filter:;
 float:none;
 font:normal normal normal 12px/16px "Helvetica Neue", Arial, sans-serif;
 height:auto;
 left:auto;
 letter-spacing:normal;
 list-style:none;
 margin:0;
 marks:none;
 max-height:auto;
 max-width:auto;
 min-height:0;
 min-width:0;
 overflow:visible;
 padding:0;
 page:auto;
 position:static;
 quotes:none;
 right:auto;
 -o-set-link-source:none;
 size:auto;
 text-align:left;
 text-decoration:none;
 text-indent:0;
 text-overflow:clip;
 text-shadow:none;
 text-transform:none;
 top:auto;
 vertical-align:baseline;
 visibility:visible;
 white-space:normal;
 width:auto;
 word-spacing:normal;
 word-wrap:normal;
 z-index:auto;
 -webkit-box-shadow:none;
 -moz-box-shadow:none;
 -ms-box-shadow:none;
 -o-box-shadow:none;
 box-shadow:none;
 -webkit-border-radius:0;
 -moz-border-radius:0;
 -ms-border-radius:0;
 -o-border-radius:0;
 border-radius:0;
 -webkit-opacity:1;
 -moz-opacity:1;
 -ms-opacity:1;
 -o-opacity:1;
 opacity:1;
 -webkit-outline:0;
 -moz-outline:0;
 -ms-outline:0;
 -o-outline:0;
 outline:0;
 -webkit-text-size-adjust:none}

这么大篇幅的reset，估计也只能说是尽量把常用的考虑进去了；具体还要看使用组件的第三方，网站的样式到底会出现什么样的特殊性。

三、css权重问题

eg6 某网站：

我们来回忆一下css写法的权重级别

important > 内联 > ID > 类 > 标签 | 伪类 | 属性选择 > 伪对象 > 继承 > 通配符

如果我们的组件是以模块的形式嵌入第三方的网站时，我们通常都以class定义；
思考如何提高我们reset样式的权重，这又是一个很纠结的问题。可能你会说，带着标签定义样式。亲，这个方法确实可行；但是，如果一个网站用id定义了一个公用样式，按着这种权重，恐怕要达到id的同级权重，只能是望尘莫及。可能你会说，那直接用id好了。确实，id的权重数字是很漂亮的，可是id与class的特殊性就在于，id在一个页面中只能出现一次。所以，如果这个组件，在此页面确实只能出现一次，那是再好不过的了。既然是组件，以其小巧灵活为优势，一个页面只出现一次，怎么能够满足我们的需求呢？所以，id的写法也会被否掉。

现在只剩下最让热痛苦的写法了：！important。这个写法确实能保证样式的级别高权重，为了去重写相关样式，覆盖reset中的定义，我们只能不断的用级别最高的定义去覆盖。但是，满篇飘红的样式对于有洁癖的前端工程师来说简直是一种折磨。

那么，保证css独立的最好办法到底是什么？其实这个办法我们都在用——iframe嵌套。但是此方法，对于需要传递数据的组件不适用。

总而言之，第三方组件想保持独立性一直都是我们在纠结的问题。从第三方的网站出发如此纠结，那我们莫不如从我们的组件出发。
我们可以将组件分为几个很简单的级别：简单的——需要很简单的几个标签及样式就可以完成；这样的组件，我们完全可以只写部分reset的css，定义很少的属性，甚至不定义都不会有大的妨碍。以节省大量的成本。复杂逻辑型——很多小模块组成的组件；就需要多在第三方网站上多下功夫了，努力完善自己组件的公用样式。

说了这么多，组件的样式reset仍然是个偶尔会让我们纠结的事。如果您是第三方网站的站长或者工程师，请记住：不管我们如何管教好我们的样式，重要的是，请您要把我们当做HTML或者XHTML标准下的代码执行，也就是说，切记，要在网站的第一行加上dtd的类型：如<!DOCTYPE HTML>或者其他的类型。

感谢 @青春的猴小野 对组件规范的制定。
如有好的方法，欢迎讨论！

（微博UDC原创博文，转载请注明出处，欢迎订阅 ）

• 你想要一个小巧的框架。
• 你需要出色的性能。
• 你需要广泛兼容标准主机上的各种 PHP 版本和配置。
• 你想要一个几乎只需 0 配置的框架。
• 你想要一个不需使用命令行的框架。
• 你想要一个不需坚守限制性编码规则的框架。
• 你对 PEAR 这种大规模集成类库不感兴趣。
• 你不希望被迫学习一门模板语言(虽然可以选择你喜欢的模板解析器)。
• 你不喜欢复杂，热爱简单。
• 你需要清晰、完善的文档。

CodeIgniter 是 @飞鱼 @给 @余果 又@给我的

(庙) miao.in 是基于 CodeIgniter 开发

改造大概花了个把小时,因为(庙)实在是太简单的网站

Disallowed Key Characters.

突然有一天出现了 Disallowed Key Characters. 这个错误,满 Google 都在说,你的 cookie 出现了非法字符

干,老子还没用到 Cookie 呢

打开Chrome调试器发现有个 Cookie 的

Key: 1345466626|7601294|43373|0|0|0

然后用 Intellij IDEA 搜了一下 "Disallowed Key Characters"

在

system/core/Input.php line 603

写着

if ( ! preg_match("/^[a-z0-9:_\/-]+$/i", $str)) { exit('Disallowed Key Characters.'); }

日哦,身为正则小王子的大猫一看眼泪都流下来

改成了

PS,这"|"不可写到"-"后面,懂的自然懂,不懂照着改

那么这个带"|"的 Cookie 哪里来的呢?

电·信·弹·窗·广·告,我·干·里·良!

2012. | Permalink | 大战3回合 | Post tags: bug, codeigniter, Disallowed Key Characters | MediaTemple | (miao) 低调滴华丽主机

部门分享 ⎡前端，改变⎦，一些个人对前端的见解和想法。有兴趣的果断关注下咯。

前端是一种介于程序和设计之间的契合，拥有程序严谨逻辑的同时也存在设计的感性，前端是设计师的代码实现更是一门艺术。

原文件 (keynote): http://vdisk.weibo.com/s/aKF_u
原文件 (pdf): http://vdisk.weibo.com/s/aKIBT

• 广告投放代码和创意代码持续优化-(第三方内容开发实战) - | 李穆/李牧 (一淘)

• Qzone前端CPU性能优化（前端性能监控与优化专场） - | 郭润增 (腾讯)

• 如何发现前端的性能问题（前端性能监控与优化专场） - | 刘杰/嗷嗷 (淘宝网)

• 百度前端性能监控与优化实践（前端性能监控与优化专场） - | 李成银 (百度)

• berserkJs（前端性能监控与优化专场） - | 钱宝坤 (新浪微博)

• 低碳的终端Web开发 - | 李晶/拔赤 (淘宝网) | 王卓/完颜 (一淘-移动UX)

• 淘宝开放产品前端实践 - | 周骞/清羽 (淘宝网) | 杨周璇/沉鱼 (淘宝网)

• 这些年，我们一起开发过的Node.js - 服务端 JavaScript Web 开发 - | 田永强/朴灵 (淘宝网)

• 阅读类 Web 应用的前端技术探索 - | 石岩 (豆瓣)

• 以 Web 的名义，向 App 告白 - | 陈虹如 (腾讯)

• 百度前端集成解决方案 - | 雷志兴 (百度)

• 编辑器设计思路 —— KindEditor & KISSY Editor & UEditor 大规模组件的模块化开发 - | 战毅 (百度) | 罗龙浩 (土豆网) | 何一鸣/承玉 (淘宝网)

开篇我们来看几个问题：

• IE6、7 真的不支持 display:inline-block 吗？
• display:inline-block 后的元素为什么会产生水平空隙，这真的是 bug 吗？
• 如何更好的解决 display:inline-block 元素间产生的水平空隙？

一、inline-block 前世

1.认知

也许有人问你为何要写「 display:inline-block; *display:inline; *zoom:1; 」 来兼容 IE6、7 时，你会立马答道：因为 IE6、7 不支持 display:inline-block 呗!不知道何时起，惯性思维给开发者带来了这样一个可怕的概念。万物都是辩证的，当你写下这些的时候，可曾怀疑过大众观点真的可靠吗？也许你认为这些无关 紧要，实现效果就好。但是如果不能理解每个属性或属性值的根本，你将永远无法全面的了解它，人云亦云只会让你浅尝辄止，止步不前。那么这里就涉及到所谓的 「CSS 学习瓶颈」的问题了，这个问题张鑫旭《说说CSS 学习中的瓶颈》一文有详细阐述，虽然部分观点我不是很赞同，但是中心思想还是很值得思考的。文中有几个不错的问题这里也列举出来供大家观摩：

1. line-height:150% 和 line-height:1.5 的区别是？
2. float 为何会让外部容器高度塌陷？这是 bug？（我的答案在《那些年我们一起清除过的浮动》）
3. vertical-align 的表现为何在IE7, IE8, IE9 下表现不尽相同？其中的渲染机制是？

好了，回到 inline-block 的认知的问题，我的观点是：

IE 从 5.5 开始就已经支持 display:inline-block 了，只是支持的并不是那么完善。

在 msdn 微软开发者社区，找到了 IE 从5.5 开始支持 inline-block 的证据：

The inline-block value is supported starting with Internet Explorer 5.5. You can use this value to give an object a layout without specifying the object’s height or width.

这里明确指出：从 IE5.5 开始支持 inline-block。

链接：http://msdn.microsoft.com/zh-cn/library/ie/ms530751(v=vs.85).aspx

那么既然 IE5.5 开始就已经支持了 inline-block，为何我们还要写那么一坨 CSS 呢？同时我们知道 IE6、7 中 display:inline-block 是可以触发 hasLayout 的，触发了 hasLayout 的元素表现出来的特征就是一个独立的矩形容器，可以设置宽高而且不受外部元素的影响，类似于现代浏览器中的 Block formatting contexts （块级格式化上下文）的概念。

下面来做一个详细的测试，分别看看 IE6 中 inline 元素和 block 元素的表现：

1）inline 元素 display:inline-block

IE6 中截图如下：

.dib-inline, .dib-block {
width:100px;
height:30px;
line-height:30px;
text-align:center;
}
.dib-inline {
display:inline-block;
}

测试表明：IE6 中 inline 元素只要触发了 hasLayout 其表现就类似于 inline-block，这里设置 display:inline-block; 或者 zoom:1; 等其他属性值可以触发 hasLayout ，表现出来是一样的。

查看 DEMO

2）block 元素 display:inline-block

IE6 中截图如下：

.dib-inline, .dib-block {
width:100px;
height:30px;
line-height:30px;
text-align:center;
}
.dib-block{
display:inline-block;
}

测试表明：IE6 中 block 元素即使触发了 hasLayout 也不能具有 inline-block 元素不换行的特性。想要 block 元素支持 inline-block 元素的特性，我们可以这样做：

.dib-block {
display:inline;
zoom:1;
}

首先让 block 元素转化为 inline 元素，强制其不换行；然后通过 zoom:1 触发 hasLayout，使其可以设置宽高。修复后的 截图如下：

3）结合现代浏览器

综上，现代浏览器都支持 display:inline-block ，IE6、7 inline 元素也可以达到同样的效果，IE6、7 block 元素需要设置 display:inline; zoom:1; 它们结合在一起便是：

display:inline-block; /* 现代浏览器 +IE6、7 inline 元素 */
*display:inline; /* IE6、7 block 元素 */
*zoom:1;

为了不让支持 CSS2.1 inline-block 的浏览器 重置为 inline，我们针对 IE6、7 做一个 hack。由于现代浏览器也开始支持 zoom 属性，这里只是希望 IE6、7 中生效，所以还是 hack 一下比较合适。至此产生了我们熟悉的兼容各个浏览器的 inline-block 写法。

小结：IE6、7 并不是不支持 inline-block，只是 block 元素需要做一些处理来达到 inline-block 的效果。

2. 到底什么是 inline-block

说了很多，或许很多朋友还不是太明白到底什么是 inline-block？W3C 在 CSS2.1 The ‘display’ property 中描述如下：

This value causes an element to generate an inline-level block container. The inside of an inline-block is formatted as a block box, and the element itself is formatted as an atomic inline-level box.

大致意思就是：inline-block 后的元素创建了一个行级的块容器，该元素内部（内容）被格式化成一个块元素，同时元素本身则被格式化成一个行内元素。

直白一点的意思就是：inline-block 的元素既具有 block 元素可以设置宽高的特性，同时又具有 inline 元素默认不换行的特性。当然不仅仅是这些特性，比如 inline-block 元素也可以设置 vertical-align 属性。简而言之：

inline-block 后的元素就是一个格式化为行内元素的块容器( Block container )

怎么样？听起来还不错吧！

3. inline-block 缘从何起？

前面已经证明了 IE 5.5 开始就支持了 inline-block，那么 IE5.5 是什么时候发布的呢？话说当年网景与 IE 大战，IE5.5 那是何等的风骚……（好吧，此处略去十页）。从维基百科的资料来看，IE5.5 beta1 的发布时间是：1999年12月，最终版本是 2000年7月。那么 W3C 标准中是何时才出现 inline-block 这个值的呢？

在 CSS1 规范中，「display」的值仅包括： block | inline | list-item | none 。CSS2.1中才添加了 inline-block 属性值。一丝继续舔着手指，用那苦逼的英语水平终于翻到了这份草案：http://www.w3.org/TR/2002/WD-CSS21-20020802/visuren.html#display-prop， 这份草案的日期是 2002年8月2日，纳尼！！！原来我们纠结了半天的 inline-block ， IE5.5 至少提前两年就提出来了啊！难道是微软给 W3C 提议后，CSS 2.1才加入的？（不过我看到 W3C 官网有一个关于是否增加 inline-block 的投票）好吧这个问题也许有一天 IE 某个开发者写《 IE回忆录》的时候我们才能了解到其中的内幕。如果找到更早关于 inline-block 的 CSS草案，也麻烦告知一丝一声。好吧，如果你还不相信，打微软官方电话问问吧 800-820-3800（不是 DHC 哦！）。

原来我们一直讨论的 inline-block 在 IE 6、7中和 CSS2.1 中的（现代浏览器所支持的） inline-block 上压根不是一个东东嘛，IE6、7 中的 inline-block 更像是 IE 的私有属性值，他们本身就不具有可比性。简单、绝对的认为 IE6、7 不支持 inline-block 好比一叶障目，看到前面，却看不到后面，太过于片面。诚然，IE6、7 的 hasLayout 给我们带来了很多麻烦，但是不得不承认微软的 IE 在网页多语言文本混排上的先进性，尤其是 CJK 文字和西文的混排，超越其他浏览器至少5年。

总结：

• IE5.5 后开始支持 inline-block， 但是它所支持的 inline-block 不能等同于 CSS2.1 中的 inline-block，因为 IE5.5 比 CSS2.1 更早提出 inline-block 的概念并作为所谓的「私有属性值」使用，所以二者表现出来的效果是不完全一致。
• IE 5.5、6、7 、8（Q）中 block 元素对 inline-block 支持不完整，如果要达到类似的效果，需要先设置为 display:inline，然后使用 zoom:1 等触发 hasLayout。
• IE 5.5、6、7 、8（Q）中 inline 元素欲达到 inline-block 的效果只需直接设置此属性值或使用 zoom:1 等均可。

各浏览器对 display 属性的支持情况请参阅：《各浏览器对 ‘display’ 特性值的支持程度不同》

二、inline-block 今生

1. display:inline-block 后的元素为什么会产生水平空隙，这真的是 bug 吗？

这么一个神奇的属性，为何大家一直避而远之呢？这恐怕还得从 inline-block 元素之间产生的水平空隙（间隙）说起吧。

参照 DEMO

• 现代浏览器中 inline 和 block 元素 display:inline-block 后均会产生水平空隙；
  
• IE6、7，IE8（Q）模拟 display:inline-block 后分两种情况：
  
  IE6、7，IE8（Q）中：inline 元素会产生空隙，block 元素不会产生空隙。

看看 inline 元素默认的表现情况如何？原来默认就有空隙存在！它们是谁？是空白符（white space）！

W3C 9.1 White space 中规定以下元素属于空白符（white space）：

• ASCII 空格 (&#x0020;)
• ASCII 制表符 (&#x0009;)
• ASCII 换页符 (&#x000C;)
• 零宽度空格 (&#x200B;)「这个在闭合浮动中也有运用到」

9.3.2 Controlling line breaks 中进一步阐述：

A line break is defined to be a carriage return (&#x000D;), a line feed (&#x000A;), or a carriage return/line feed pair. All line breaks constitute white space.

For more information about SGML’s specification of line breaks, please consult the notes on line breaks in the appendix.

折行被定义为一个回车符（&#x000D;），一个换行符 line feed (&#x000A;)，或者一个回车、换行的组合。所有的折行构成了空白符。

有关 SGML 规范中折行的更多信息，请参阅附录中关于折行的注释。

通常情况下，对于多个连续的空白符（空格，换行符，回车符等），浏览器会将他们合并为一个空白符。CSS 中由 white-space 这个属性来控制：

white-space：normal | pre | nowrap | pre-wrap | pre-line

默认值：normal

• normal：默认处理方式。
• pre：用等宽字体显示预先格式化的文本，不合并文字间的空白距离，当文字超出边界时不换行。可查阅 pre 对象
• nowrap：强制在同一行内显示所有文本，直到文本结束或者遭遇 br 对象。
• pre-wrap：用等宽字体显示预先格式化的文本，不合并文字间的空白距离，当文字碰到边界时发生换行。
• pre-line：保持文本的换行，不保留文字间的空白距离，当文字碰到边界时发生换行。

注：IE7及更早浏览器不支持 CSS2.1 新增的 pre-wrap | pre-line。

所以这并不是 inline-block 后产生的 bug，而是因为 inline-block 具有 inline 元素固有的特性。那么为何 IE6、7 block 元素没有产生空隙呢？其实前面也提到了 IE 的 hasLayout，具有独立性，所以产生 hasLayout 的元素之间表现出来互不影响，这也再次表明 IE6、7 中的 inline-block 不能等同于 CSS2.1 中的 inline-block。如果非要说是有 bug， IE6、7 block 元素 inline-block 后不产生空隙才是 bug。

测试表明删除换行符后，inline 元素间的空隙就「消失」了：

2.去掉 inline-block 产生的空隙

为了让各个浏览器表现一致，更好的还原视觉设计搞，很多时候我们需要去掉 inline-block 产生的空隙。

上一节中我们已经知道产生空隙的根本性原因是：

HTML 中的换行符、空格符、制表符等产生了空白符，而这些归根结底都是字符，那么它们的大小都是 受 font-size 来控制的，字体大小直接导致 inline 或者 inline-block 后元素之间空隙的大小，把 inline-block 元素间的空隙认为总是某个固定大小是错误的。

用 GIF 动画的形式来表明对应关系：

很清楚的看到，当 font-size:0 的时候元素间的空隙都为0了，或许到这里你会感到很欣喜了，原来掌握的根本性原因这么简单就搞定了啊！

然，理想是丰满的，现实是骨感的。

大部分浏览器是支持 font-size:0 的。很明显，我们要和 IE 6、7 这两个妖孽进行一番战斗。

font-size:0 的支持情况

1）Chrome

低版本的 chrome 浏览器为了不让文字过小不利于阅读，默认是不支持 font-size:0 的，还好我们有 -webkit-text-size-adjust 这个私有属性来控制，当设为 none 时就支持字体大小为 0 了。我已经记不清楚 chrome 从哪个版本开始支持 font-size:0 了，反正我用 chrome 19 是支持了（有知道的朋友，烦请告诉一丝一声，最好有官方更新说明）。但是，-webkit-text-size-adjust:none; 会直接导致页面文字无法缩放，这对于用户来说显然是不友好的。所以-webkit-text-size-adjust:none; 一定要慎用，确保使用的地方没有大面积的文字。

-webkit-text-size-adjust:none 的使用场景实例参阅：http://vip.etao.com/

2）Safari

Safari 5 依旧不支持 font-size:0 ，不过相信这些浏览器厂商都意识到了这个问题，在 Mac 平台最新的 Safari 6 已经很好的支持 font-size:0 了。

3）Firefox，Opera

经测试，Firefox12，Opera 10 ，这次表现不错，支持 font-size:0 。

4）IE

• IE8 以上支持 font-size:0;
• IE6、7 inline 元素 inline-block 后设置 font-size:0 始终有 1px 的空隙。

是不是一下子又开始头疼了？没关系，让我们请出 letter-spacing 和 word-spacing 二位大神。既然空白符也是字符，那么二位大神肯定是可以搞定它们的。

• letter-spacing : normal | length （检索或设置对象中的文字之间的间隔）
• word-spacing : normal | length（检索或设置对象中的单词之间插入的空隔）

normal： 默认间隔
length： 用长度值指定间隔，允许为负值。

还等什么，我们赶紧试试吧：

参照 DEMO

• 第一步：使用 font-size:0经测试发现，chrome、firefox、IE8+、opera，inline 或 block 元素都没有空隙了；
  Safari 5.1.7 由于不支持 font-size:0 ，仍然存在空隙；
  
  
  IE6、7、8（Q），inline 元素 inline-block 后始终存在 1px 左右的空隙。
• 第二步：处理 Safari 不支持 font-size:0 的问题上面已经指出 letter-spacing 是支持负值的，那么这个负值到底取多少合适呢？经过测试得出的结论是：inline-block 产生的空隙与父级元素继承或者设定的 font-family、font-size 有关，通常情况下，12px 大小的 tahoma 字体，inline-block 后元素间产生的空隙（间隙）大约是 5px；
  各个字体详细情况请参阅《inline-block空隙–letter-spacing与字体大小/字体关系数据表》。Firefox 中 letter-spacing 负值的绝对值大于空隙大小后，会导致元素整体位置向右偏移；
  Safari 中 letter-spacing 负值的绝对值大于空隙大小后，内部会发生重叠。
• 第三步：修复 IE6、7 中始终存在的 1px 空隙
  既然 letter-spacing 已经无能为力了，那就试试 word-spacing 吧，直接设置 word-spacing:-1px。这里需要注意的是，letter-spacing 和 word-spacing 同时使用可能导致冲突，所以我们需要在 IE6、7 中 hack 掉 letter-spacing。最终代码如下：

font-size:0;/* 所有浏览器 */
letter-spacing:-5px;/* Safari 等不支持字体大小为 0 的浏览器 */
*letter-spacing:normal;
word-spacing:-1px;/* IE6、7 */

• 第四步：子元素重置回正常值
  上述所有操作都是在父元素设置的，那么子元素都会继承这些属性，字体大小为0了，子元素就什么都看不到了，这并不是我们想要的。 同时字符和单词间距我们也要把它重置为默认值。「font-size: 12px; letter-spacing: normal; word-spacing: normal;」
• 最后：inline-block 更好的复用
  或许你会担心每次我都要去看字体和空隙之间大小的关系吗？其实不然，通常情况下，全局字体都已经在 body 中指定了，根据全局字体设置合适的 letter-spacing 负值即可。如此一来，我们便可以放心大胆的使用 inline-block 了，结合 OOCSS 的思想，可以抽离出两个复用的类，在需要设置 inline-block 元素的父级元素上定义一个「.dib-wrap」，该元素自身定义为「.dib」。这里还有一个问题需要注意的是：由于 inline-block 具有 inline 元素的特性，在垂直方向上很多时候我们并不希望元素以「vertical-align:baseline」方式来呈现，所以在「.dib-wrap」中统一重置为「vertical-align:top」即可。

3. 去除 inline-block 空隙终极解决方案

.dib {
display: inline-block;
*display:inline;
*zoom:1;
}
.dib-wrap {
font-size:0;/* 所有浏览器 */
letter-spacing:-Npx;/* Safari 等不支持字体大小为 0 的浏览器 N 根据父级字体调节*/
*letter-spacing:normal;
word-spacing:-1px;/* IE6、7 */
}
.dib-wrap .dib{
font-size: 12px;
letter-spacing: normal;
word-spacing: normal;
vertical-align: top;
}

其实在 YUI 3 中也全面运用了 inline-block 作为基础布局，YUI 3 是这样解决的：

.yui3-g {
letter-spacing: -0.31em; /* webkit: collapse white-space between units */
*letter-spacing: normal; /* reset IE < 8 */
word-spacing: -0.43em; /* IE < 8 && gecko: collapse white-space between units */
}

.yui3-u {
display: inline-block;
zoom: 1; *display: inline; /* IE < 8: fake inline-block */
letter-spacing: normal;
word-spacing: normal;
vertical-align: top;
}

显然，这里纯粹使用了 letter-spacing 和 word-spacing 来控制元素间的空隙，局限性极大，-0.31em 和 -0.43em 只是因为 YUI 3 全局 cssfonts.css 里设置是：「body { font:13px/1.231 arial,helvetica,clean,sans-serif; }」。

当然，如果你坚持使用把 html 写在一行的方式来达到去除 inline-block 空隙的目的，我只能说：一切以牺牲结构来兼容表现的行为都是耍流氓！所以探讨此种方式去除空隙也将是无意义的，不在本文和作者考虑范围之内。

4. 结局——本文产生的一些观点如下：

• IE5.5 后开始支持 inline-block， 比 CSS2.1 更早提出 inline-block 的概念并作为所谓的「私有属性值」使用。但是它所支持的 inline-block 不能等同于 CSS2.1 中的 inline-block，IE 5.5、6、7 、8（Q）中 block 元素对 inline-block 支持不完整，因此二者表现出来的效果是不完全一致。
• 产生 inline-block 空隙的根本性原因是：HTML 中的换行符、空格符、制表符等合并为空白符，字体大小不为 0 的情况下，空白符自然占据一定的宽度，因此产生了元素间的空隙。
• 慎用 -webkit-text-size-adjust:none，它将会导致页面无法通过缩放来改变字体大小。

三、inline-block 未来

如今，Mac 平台下的 Safari 6 已经支持 font-size:0 了，相信很快 Windows 平台的 Safari 如果发布 5.X 的更新，也会支持字体为 font-size:0 了。等到 IE6、7 灭亡之后，世界就真真儿的美妙了！最后说一点：inline-block 与 float 也是无法直接比较的，请不要再讨论 inline-block 和 float 哪个更好的话题了。inline-block 从 IE5.5 一路走来，存在即是合理，以后有时间在总结一下 inline-block 与 float 的使用场景的区别。

在不改变 CSS 定位机制的前提下，inline-block 应该是首选，而不是以「奇淫技巧」存在的。有感打油诗一首：

网事如烟
CSS 红尘里
inline-block 知多少
你在这头
inline-block 在那头
用与不用
它就在那里
不悲不喜

PS：

1. 为了更好的排版，本文使用繁体中文引号 「」代替简体中文小蝌蚪引号；
2. 中英文混排的时候英文首尾各加一个空格；
3. 以后文章有需要的时候也都将使用 gif 动画配合说明。

测试环境

一丝
2012-8-10 于杭州

HTML5已经出来好长时间了，越来越多人希望并且开始把HTML5应用到平时的工作、个站中。大家对section、article、aside、nav等新标签的使用也越来越上手，也许是自我感觉良好的上手。不从多个方面去认识理解这些标签，可能反而让自己落入了更混乱的境地。HTML的大纲算法(outlining algorithm)就是一个很重要的切入点。

先看两个大纲：

这两个都是我早期的作品了。当时还觉得自己的结构写的不错，特别是第二个，还用上了HTML5标签，以为自己就踏进这个新世界了。看过HTML大纲算法之后，检测了一下这些页面，真的是惨不忍睹。第一个各种混乱标题不说，“主创阵容”居然从属于“用户评论”？第二个也不好发言了，那么多未命名的是什么东西？不过总是要踩在伤痛的历史上才能往前进。

再来看几个其他人重构的页面大纲：

想象你是一个有点视力障碍的用户，需要依靠屏幕阅读器来浏览这些网页，阅读器会按照层级来给你解读这个网页，你觉得上面那个网页更容易让你获得所需要的资讯呢？也许对比完大家更想知道大纲算法到底是个怎么样的东西了吧？

什么是HTML大纲算法？

大纲算法允许用户代理(user agent)从一个web页面生成一个信息结构目录，让用户对页面有一个快速的概览。类似书籍、PDF、帮助文档等，都有一个清晰的目录结构，用户能方便的定位所需内容。一个良好结构的大纲，不仅是对于搜索引擎的优化，更是为借助于屏幕阅读器浏览网页的盲人（或弱视力）用户提供了巨大的帮助。

帮助文档的目录结构：

每个页面都有大纲，先从一个简单的例子来了解web页面大纲吧。假设要做一个电影介绍页面，主题是8月电影推介，页面结构也许如下：

1.8月电影推介
  1.国内电影
    1.《四大名捕》
    2.《搜索》
  2.国外电影
    1.《冰川时代4》
    2.《在劫难逃》

HTML4或者之前，我们都是采用hn（h1~h6）来生成大纲的。HTML5引入了section、article、aside、nav等新的节点元素(sectioning content)，添加了一些新的规则，后面会详细阐述。

hn生成的大纲

也许HTML4的结构会这样写：

<div>
  <h1>8月电影推介</h1>

  <h2>国内电影</h2>
  <h3>《四大名捕》</h3>
  <p>四大名捕讲的是..</p>
  <h3>《搜索》</h3>
  <p>搜索讲的是..</p>

  <h2>国外电影</h2>
  <h3>《冰川时代4》</h3>
  <p>冰川时代4讲的是..</p>
  <h3>《在劫难逃》</h3>
  <p>在劫难逃讲的是..</p>

  <p>以上内容由迅雷看看提供</p>
<div>

可以看出，网页大纲由标题的层级来生成。

如果想要查看这段代码的大纲，可以试试Geoffrey Sneddon做的大纲工具Outliner（强烈推荐），上传文件和输入片段代码都可以。如果想要查看在线网页的大纲，可以给浏览器安装插件：chrome：HTML5 Outliner（推荐）/ Web Devoloper，firefox：Web Devoloper；opera：HTML5 Outliner。（HTML5 Outliner里中文会显示乱码，建议换成英文测试。浏览器插件可以显示中文）

每个标题都会生成一个隐性节点(implicit section)，紧随其后的相对层级低的标题会成为它的子节点，层级相同或者更高的标题则会关闭这个节点并生成新的节点。可以测试一下下面的代码：

<h3>《四大名捕》</h3>
<p>四大名捕讲的是..</p>
<h3>《搜索》</h3>
<p>搜索讲的是..</p>

或者：

<h3>《搜索》</h3>
<p>搜索讲的是..</p>
<h2>国外电影</h2>

节点元素生成的大纲

也许HTML5的结构会这样写：

<div>
  <h6>8月电影推介</h6>

  <section>
    <h1>国内电影</h1>
    <article>
      <h1>《四大名捕》</h1>
      <p>四大名捕讲的是..</p>
    </article>
    <article>
      <h3>《搜索》</h3>
      <p>搜索讲的是..</p>
    </article>
  </section>

  <section>
    <h5>国外电影</h5>
    <article>
      <h6>《冰川时代4》</h6>
      <p>冰川时代4讲的是..</p>
    </article>
    <article>
      <h1>《在劫难逃》</h1>
      <p>在劫难逃讲的是..</p>
    </article>
  </section>

  <p>以上内容由迅雷看看提供</p>
<div>

（可以先注意一下上面这段代码的各个hn）把代码复制到Outliner工具去查看，很惊讶的发现，生成的大纲跟层级写的很漂亮的HTML4一样。为什么hn的层级在这里没有表现出来？

原因是此时大纲是由节点元素生成的，而非标题元素。HTML5的新标签section、article、aside、nav会生成显性节点(explicit sections)，每个显性节点内部又有它自己的标题结构（当然也符合HTML4、HTML5大纲算法）。这也就是为什么HTML5允许多个h1存在的原因，不过，在全部浏览器、屏幕阅读器都完美支持HTML5之前，建议还是需要同时考虑标题结构，优雅降级。所以上面的结构可以改成这样：

<div>
  <h1>8月电影推介</h1>

  <section>
    <h2>国内电影</h2>
    <article>
      <h3>《四大名捕》</h3>
      <p>四大名捕讲的是..</p>
    </article>
    <article>
      <h3>《搜索》</h3>
      <p>搜索讲的是..</p>
    </article>
  </section>

  <section>
    <h2>国外电影</h2>
    <article>
      <h3>《冰川时代4》</h3>
      <p>冰川时代4讲的是..</p>
    </article>
    <article>
      <h3>《在劫难逃》</h3>
      <p>在劫难逃讲的是..</p>
    </article>
  </section>

  <p>以上内容由迅雷看看提供</p>
<div>

这里有另外一个问题值得注意，就是“以上内容由迅雷看看提供”这段话指的是上面的哪部分内容？在HTML4结构里，这段话是从属于隐性节点“《在劫难逃》”的，但明显不对。HTML5大纲算法就很好地解决了这个问题。

hn和节点元素同时生成大纲

如果页面里既有隐性节点（h1~h6）又有显性节点（section等），大纲又会如何生成呢？只要记住一点：显性节点能包含隐性节点，反之则不行。

<h1>8月电影推介</h1>
<section>
  <h2>国内电影</h2>
  <h3>《四大名捕》</h3>
  <p>四大名捕讲的是..</p>
  <h3>《搜索》</h3>
  <p>搜索讲的是..</p>
</section>

（代码1）

这段代码的大纲会是：

1.8月电影推介
  1.国内电影
    1.《四大名捕》
    2.《搜索》

<h1>8月电影推介</h1>
<h2>国内电影</h2>
<article>
  <h3>《四大名捕》</h3>
  <p>四大名捕讲的是..</p>
</article>
<article>
  <h3>《搜索》</h3>
  <p>搜索讲的是..</p>
</article>

然而这段代码的大纲会是：

1.8月电影推介
  1.国内电影
  2.《四大名捕》
  3.《搜索》

由标题元素生成的隐性节点遇上由节点元素生成的显性节点就会关闭并生成下一个同级节点。

未命名节点(untitled sections)

HTML5新节点元素除了section、article还有aside、nav，我们也来使用一下。

<nav>
  <ul>
    <li><a href="">首页</a></li>
    <li><a href="">专题</a></li>
    <li><a href="">关于</a></li>
  </ul>
</nav>
<h1>8月电影推介</h1>
<section>
  <h2>国内电影</h2>
</section>
<section>
  <h2>国外电影</h2>
</section>

复制到outliner会发现， nav标签会产生一个untitled section，因为nav里并没有给予任何标题元素。这不是错误也不会被认为是不好的HTML5结构。但是section、article还是建议给予适当的标题。如果不确定可以给予什么标题，也许使用div更适合，不要忘了我们还有div啊。

根节点

前面提到一个重要的原则：显性节点能包含隐性节点，反之则不行。也许你会注意代码1生成的大纲：

1.8月电影推介
  1.国内电影
    1.《四大名捕》
    2.《搜索》

标题元素h1（“8月电影推介”）下紧跟着的节点元素section（“国内电影”），变成了它的一个子节点。隐性节点不是不能包含显性节点么？这时候就需要认识一下根节点了。

根节点可以生成自己的大纲，它的标题和节点对祖先的大纲没有任何影响（而且不会出现在祖先大纲里）。目前有六个根节点：

1.body

2.blockquote

3.details

4.fieldset

5.figure

6.td

可以测试一下：

<h1>我是老大 I'm the big brother</h1>
<blockquote>
  <section>
    <h1>我是blockquote里的老大，待会你看不到我了 I'm the big brother in blockquote,you'll not find me in the outliner</h1>
  </section>
</blockquote>
<h2>我是老二 I'm the younger</h2>

定义文档里说明了：节点元素是离它最近的祖先根节点或节点元素的子节点。代码1里的标题元素h1（“8月电影推介”）是body的标题，节点元素section（“国内电影”）是body的子节点。

还有一个很重要的：文档的标题是文档中第一个且非节点元素里的标题元素。测试一下下面的代码就很明了了：

<section>
  <h1>我很想成为文档的标题可惜不能 I want to be the title but I couldn't</h1>
</section>
<h6>虽然我层级最小可是我是第一个出现的 I'm h6 but I come first</h6>
<h1>最大也没用顺序我还是在老6下面 I'm h1 but I come after h6</h1>

过程中我还遇到过另一个让我迷惑的：

<section>
  <h1>我很想成为文档的标题可惜不能 I want to be the title but I couldn't</h1>
</section>
<section>
  <h2>我也很想成为文档的标题可惜不能 Me either:(</h2>
</section>
<footer>
  <h3>我是footer可是为什么我成为了文档标题啊 I'm footer but why I become the title??</h3>
</footer>

原因很简单，header和footer不是节点元素。

hgroup

hgroup很好理解也很好用，它的作用就是帮你添加副标题而不影响文档大纲，大纲中只会出现层级最高的标题，无论出现顺序。

<hgroup>
  <h3>我是副标题，我很重要但我不会出现在大纲中 I'm your loved second title,I'm useful and I won't appear in the outliner</h3>
  <h2>我是大标题，我是故意跑到下面来的 I'm the highest level of hn in the group,no matter where I am,I will be part of ouliner</h2>
</hgroup>

总结

到写完这篇文章为止，好像还没有哪个浏览器是完美支持HTML5大纲算法的。但这不影响我们对HTML5大纲算法的学习，就像我们现在在努力使用HTML5+CSS3一样。理解了HTML5大纲算法，不仅对于新标签的使用有更进一步的认识，而且对于最根本的页面结构有更优化的理解，就算只是标题元素生成的大纲，也能拥有完美的层级结构，这也是语义化的一个标志。

特别感谢一下大安仔，是他提醒我要注意这个问题的。

认为setTimeout中的问候方法会立即被执行,因为这并不是凭空而说,而是JavaScript API文档明确定义第二个参数意义为隔多少毫秒后,回调方法就会被执行. 这里设成0毫秒,理所当然就立即被执行了.
同理对setInterval的callbackFunction方法每间隔100毫秒就立即被执行深信不疑!

但随着JavaScript应用开发经验不断的增加和丰富,有一天你发现了一段怪异的代码而百思不得其解:

既然是0毫秒后执行,那么还用setTimeout干什么, 此刻, 坚定的信念已开始动摇.

直到最后某一天 , 你不小心写了一段糟糕的代码:

第一行代码进入了死循环,但不久你就会发现,第二,第三行并不是预料中的事情,alert问候未见出现,callbacKFunction也杳无音讯!

这时你彻底迷惘了,这种情景是难以接受的,因为改变长久以来既定的认知去接受新思想的过程是痛苦的,但情事实摆在眼前,对JavaScript真理的探求并不会因为痛苦而停止,下面让我们来展开JavaScript线程和定时器探索之旅!

拔开云雾见月明

出现上面所有误区的最主要一个原因是:潜意识中认为,JavaScript引擎有多个线程在执行,JavaScript的定时器回调函数是异步执行的.

而事实上的,JavaScript使用了障眼法,在多数时候骗过了我们的眼睛,这里背光得澄清一个事实:

JavaScript引擎是单线程运行的,浏览器无论在什么时候都只且只有一个线程在运行JavaScript程序.

JavaScript引擎用单线程运行也是有意义的,单线程不必理会线程同步这些复杂的问题,问题得到简化.

那么单线程的JavaScript引擎是怎么配合浏览器内核处理这些定时器和响应浏览器事件的呢?
下面结合浏览器内核处理方式简单说明.

浏览器内核实现允许多个线程异步执行,这些线程在内核制控下相互配合以保持同步.假如某一浏览器内核的实现至少有三个常驻线程:javascript引擎线程,界面渲染线程,浏览器事件触发线程,除些以外,也有一些执行完就终止的线程,如Http请求线程,这些异步线程都会产生不同的异步事件,下面通过一个图来阐明单线程的JavaScript引擎与另外那些线程是怎样互动通信的.虽然每个浏览器内核实现细节不同,但这其中的调用原理都是大同小异.

Js线程图示

由图可看出,浏览器中的JavaScript引擎是基于事件驱动的,这里的事件可看作是浏览器派给它的各种任务,这些任务可以源自JavaScript引擎当前执行的代码块,如调用setTimeout添加一个任务,也可来自浏览器内核的其它线程,如界面元素鼠标点击事件,定时触发器时间到达通知,异步请求状态变更通知等.从代码角度看来任务实体就是各种回调函数,JavaScript引擎一直等待着任务队列中任务的到来.由于单线程关系,这些任务得进行排队,一个接着一个被引擎处理.

上图t1-t2..tn表示不同的时间点,tn下面对应的小方块代表该时间点的任务,假设现在是t1时刻,引擎运行在t1对应的任务方块代码内,在这个时间点内,我们来描述一下浏览器内核其它线程的状态.

t1时刻:

GUI渲染线程:

该线程负责渲染浏览器界面HTML元素,当界面需要重绘(Repaint)或由于某种操作引发回流(reflow)时,该线程就会执行.本文虽然重点解释JavaScript定时机制,但这时有必要说说渲染线程,因为该线程与JavaScript引擎线程是互斥的,这容易理解,因为JavaScript脚本是可操纵DOM元素,在修改这些元素属性同时渲染界面,那么渲染线程前后获得的元素数据就可能不一致了.

在JavaScript引擎运行脚本期间,浏览器渲染线程都是处于挂起状态的,也就是说被”冻结”了.

所以,在脚本中执行对界面进行更新操作,如添加结点,删除结点或改变结点的外观等更新并不会立即体现出来,这些操作将保存在一个队列中,待JavaScript引擎空闲时才有机会渲染出来.

GUI事件触发线程:

JavaScript脚本的执行不影响html元素事件的触发,在t1时间段内,首先是用户点击了一个鼠标键,点击被浏览器事件触发线程捕捉后形成一个鼠标点击事件,由图可知,对于JavaScript引擎线程来说,这事件是由其它线程异步传到任务队列尾的,由于引擎正在处理t1时的任务,这个鼠标点击事件正在等待处理.

定时触发线程:

注意这里的浏览器模型定时计数器并不是由JavaScript引擎计数的,因为JavaScript引擎是单线程的,如果处于阻塞线程状态就计不了时,它必须依赖外部来计时并触发定时,所以队列中的定时事件也是异步事件.

由图可知,在这t1的时间段内,继鼠标点击事件触发后,先前已设置的setTimeout定时也到达了,此刻对JavaScript引擎来说,定时触发线程产生了一个异步定时事件并放到任务队列中, 该事件被排到点击事件回调之后,等待处理.
同理, 还是在t1时间段内,接下来某个setInterval定时器也被添加了,由于是间隔定时,在t1段内连续被触发了两次,这两个事件被排到队尾等待处理.

可见,假如时间段t1非常长,远大于setInterval的定时间隔,那么定时触发线程就会源源不断的产生异步定时事件并放到任务队列尾而不管它们是否已被处理,但一旦t1和最先的定时事件前面的任务已处理完,这些排列中的定时事件就依次不间断的被执行,这是因为,对于JavaScript引擎来说,在处理队列中的各任务处理方式都是一样的,只是处理的次序不同而已.

t1过后,也就是说当前处理的任务已返回,JavaScript引擎会检查任务队列,发现当前队列非空,就取出t2下面对应的任务执行,其它时间依此类推,由此看来:

如果队列非空,引擎就从队列头取出一个任务,直到该任务处理完,即返回后引擎接着运行下一个任务,在任务没返回前队列中的其它任务是没法被执行的.

相信您现在已经很清楚JavaScript是否可多线程,也了解理解JavaScript定时器运行机制了,下面我们来对一些案例进行分析:

案例1:setTimeout与setInterval

这两段代码看一起效果一样,其实非也,第一段中回调函数内的setTimeout是JavaScript引擎执行后再设置新的setTimeout定时, 假定上一个回调处理完到下一个回调开始处理为一个时间间隔,理论两个setTimeout回调执行时间间隔>=10ms .第二段自setInterval设置定时后,定时触发线程就会源源不断的每隔十秒产生异步定时事件并放到任务队列尾,理论上两个setInterval回调执行时间间隔<=10.

案例2:ajax异步请求是否真的异步?

很多同学朋友搞不清楚,既然说JavaScript是单线程运行的,那么XMLHttpRequest在连接后是否真的异步?
其实请求确实是异步的,不过这请求是由浏览器新开一个线程请求(参见上图),当请求的状态变更时,如果先前已设置回调,这异步线程就产生状态变更事件放到JavaScript引擎的处理队列中等待处理,当任务被处理时,JavaScript引擎始终是单线程运行回调函数,具体点即还是单线程运行onreadystatechange所设置的函数.

来源：集思网