Web Design Is 95% Typography，这并不夸张。尽管我不是设计师，和字体打交道的时间相对较少，却也知道其重要性。不过 Typography 一词并没有非常正式的官方中译，通常称为“字体排印”，而我们Web开发者讨论的也只是其中一个子集 Web typography。对此我没有什么深入研究，我强烈推荐 Type is Beautiful Blog，不论是Web开发者还是设计师，都应该对 Typography 这个我们日常工作内容的超集有所了解——对于前端恐怕尤为如此，毕竟浏览器便是此分支中的一个排版引擎。
本文主要讨论的是 WOFF，以及 Google Font API 中 WOFF 调用的相关应用。
QR code
QR code ，Quick Response code，是一种流行的2维条形码，能够存储多达4296个字母数字字符的任意文本，对于汉字，做多存储1817个，相对于177×177这么小一块区域来说容量已经相当高，更重要的是读取速度——准确而高效，因而在各个领域都有非常广泛的应该。导致现在手机读取条码软件也是相当流行。
Google Chart API 里就有专门的 QR code 生成调用，能非常方便的获取自己想要的 QR code。配图的内容为 swordair.com，长宽为150px，由google生成，看起来还挺不错挺蛋疼的。 如果只是随便玩一下，网络上也有在线的QR code 生成工具，使用起来更加便捷。
问题在于，我们拿着这幅自己完全看不懂的图做什么？用来写情书吗？恐怕是个不错的主意，绕这么多圈子想不收卡都难了，哈哈。
难得闲来无事，对此API我就简单封装了一个QRcode.js，方便日常使用。好吧，我常常写情书，而且一写就停不下来:)
当然，卡也就没少收了…
这里聚合了我了解的JS绘图库——特别是图表库，在很多应用方面已经显得非常成熟。现代浏览器都能很好的支持，对于IE9以下它们多半都是用ExCanvas模拟实现。尽管对于绘图和图表，Flash仍然是当前最为理想和流行的方案，不过相信未来，canvas会成为主流。
CSS代码工具界从来没有像现在这么繁荣——随着CSS3的渐渐流行，复杂样式的编写迫切需要有代码的生成工具简化编写的难度和节约时间。于是各种各样的工具在一年间到处开花，现在多到需要自己挑选的地步。本文虽然写的是我自己常用的生成器，但在文中链接里还能找到更多。这些工具不仅帮助我们节省无意义时间的小号，而且对于CSS3新手来说，通过生成器有针对性的学习新属性也不失为一种捷径。
前段时间，论坛一个投票帖子，问一个前端，如果给出一台新的电脑，你能用多久准备好各种环境？结果现在是选择半天的人占了大多数。需要多少时间和环境的复杂度有很大关系，我自己的环境估计没有一天是不行的，这还没算上各种虚拟机的情况。如果不算各种软件的下载时间，我也至少需要大半天时间。帖子的楼主列举了一些列他常用的前端软件，后来想了一想，自己也应该准备一份清单，在系统重装或者崩溃的时候迅速恢复到正常的工作和日常…对，日常需要的也应该列入在内。
text-shadow作为CSS3里被现代浏览器支持最早、也是最广的属性，我们对它已经非常熟悉。现代浏览器除了IE9之外，全部无前缀支持text-shadow。和box-shadow类似，但远没有box-shadow那么复杂。它的作用只是对文本添加阴影:
text-shadow: 2px 2px 3px blue;
其用法有大致上有两种，一种是在浅色背景上应用深色阴影凸显出文字的层次。另一种，就是在深色背景上使用浅色阴影创造出类似浮雕的内嵌的效果。最后用的比较少的，就是单纯的雾化文本，也就是X和Y的偏移设为0——不过这样对文本的可读性没什么好处，也没什么技术含量，所以完全不值得提倡。淘宝曾在首页的热卖单品区单纯的使用text-shadow雾化文本，但现在已经移除了这种蛋疼的效果。
我并不打算花时间展开text-shadow，因为这个属性相当简单，所以text-shadow本身并不是本文的重点。这里要写的是：text-shadow在Chrome下的bug以及关于这个bug的一些有趣的事。
前几天，一位叫做colin朋友邮件问了我一个关于包含块的疑问，大致是说，css2.1定义里有这样一句：
“For other elements, if the element’s position is ‘relative’ or ‘static’, the containing block is formed by the content edge of the nearest block container ancestor box.
但是国内的翻译资料，却是这样的：
它的包含块由它最近的块级、单元格（table cell）或者行内块（inline-block）祖先元素的内容框创建
到底包不包括行内块(inline-block)？
凭着一些以前对CSS标准的印象，我模糊地给出了一个我的理解，即inline-block虽然对外是行内元素，但是其内部格式化成块，所以仍然属于block container。虽然也没有错误，但显然不够清晰，也没能给出标准的参考依据。于是今天乘着有空翻了一下标准，发现自己的有部分知识结构随着时间慢慢模糊掉了，不过好在有印象，花一点时间能串的起来。
延迟加载 Lazy Loading 是一种设计模式，和预加载 Preloading 相反，最简单的说法就是“按需加载”。如果用在网页里，最多的就是图片的延迟加载。对于一张自上而下的充满图片的页面，尤其是图片列表形式，Lazy Loading的效果会非常的明显，能大幅提高加载速度和体验。大概是近期发觉自己博客里的图片日益变多，所以就打算赶下流行（似乎很大一部分博客都有使用），也简单做一下图片延迟加载。
虽然大部分的框架和插件都提供类似功能，但是代码原理也大都是类似——获取视点即viewpoint的高宽、图片的位置以及当前浏览页面部分的位置，由此判断图片是否在我们的浏览范围之内，如果是则加载它。但在具体做的时候也有很多差异，保存原来图片的src、移除src、判断是否加载、移除已经加载的事件或者数组元素等等，这些通常都有。以JQuery插件LAZY LOAD为例，它就是用增加的original属性保存原来图片的src，然后再按需加载它们。
虽然微弱，但IE6确实正在慢慢地死去。针对IE6的知识同样渐渐过时。针对IE6的知识同样渐渐过时。不过这也是因为自己整天做的是针对国外的网站，这种感觉才越发强烈。
本文会在2011年内持续更新。我会把我知道的各种零碎的关于IE6的东西整理出来。这些东西都将会随着IE6消亡。这些东西都将会随着IE6消亡，慢慢淡出前端工作者的视线，但是它们存在过，并且我列举的都是陪着我一路走过来的资料，我从这些地方学到了很多。
今后的一年里我要穷举出自己经历的IE6，一个我眼中的IE6。同时，往前看，一个新的IE6正在前方等着我们:)
人一旦被一些繁杂的事消耗掉精力的话，即使有时间静下心来写篇东西也变得那么的不易啊，呵呵。题外话就不多说了，真没想到这篇早就构思好的东西写了这么久…
阅读本文请使用chrome，Opera或者FireFox浏览器。
在上一篇的CSS3 box-shadow 详解(1)里，我从标准的角度出发，详细地写到了box-shadow的标准的方方面面。但毕竟是游戏规则似的细节，读起来恐怕还是没什么味道，按照上次的安排，这篇里不再牵扯标准的任何细节性的东西，主要就是讲实际应用中，box-shadow能做些什么。
