这段时间确实比较繁忙，所以博客一直都没什么产出:)

前段时间看到一篇《9个你现在可以使用的CSS3属性( 9 CSS3 Properties You Can Use Now)》，描述了当前可以渐进使用的CSS3的新的属性。但实际上由于种种原因，当前能使用的其实远达不到9个这么多。

本文讨论的就是其中之一，box-shadow，而且是从比较细节的角度。既然是详解就必然要写的详尽，于是，写到一半的时候才发觉内容太多，所以就分成了2个章节。这个章节里讨论box-shadow标准的描述，所以你能知道一些非常细节的东西，当然这些东西都没法使用，所以如果你只是想了解怎么使用box-shadow，请跳过这一章，直接阅读我写的《CSS3 box-shadow 详解(2)》，那里我会写记录些常用的或者是有趣的使用方法。

和往常一样，我先是查找了国内已经有人写过的内容避免自己写的和他们的有所冲突。和我之前写 CSS3 Media Query 时的没有多少好文的情况不同，关于box-shadow已经涌现出了很大的一批内容，所以后面的描述中我将援引他们。

正如标题所示，这里讨论的是CSS3的box-shadow，所以并没有打算讨论过时浏览器的模拟。关于模拟的这方面内容可以参看张鑫旭的《CSS实现跨浏览器兼容性的盒阴影效果》和《CSS实现跨浏览器的box-shadow盒阴影效果(2)》，或者是小鱼的《跨浏览器实现投影(box-shadow)那点事》。

下面，确保你的浏览器是非IE，然后就开始正题吧:)

从标准开始

W3C标准里关于box-shadow的定义内容其实并不多，花上一小块时间就能看完。

The ‘box-shadow’ property attaches one or more drop-shadows to the box. The property is a comma-separated list of shadows, each specified by 2-4 length values, an optional color, and an optional ‘inset’ keyword. Omitted lengths are 0; omitted colors are a UA-chosen color.

这里没有多少值得说的地方，唯一需要关注的是box-shadow可以使用 1个 或 多个投影，类型可以是默认的投影，以及可选的阴影内嵌，这点在后面的应用中可以利用。表达式如下：

<shadow> = inset? && [ <length>{2,4} && <color>? ]

表达式非常直观，但不是经常看的人可能不是很习惯。这个属性定义了2-4个长度值，以及两个可选值inset和color。同时定义里也描述了默认值，长度默认为0，颜色默认为UA所选的颜色（通常是浏览器默认值黑色，但浏览器是有差异的）。或许mozilla给出的定义更为直观些：

box-shadow:  none | <shadow> [,<shadow>]*
where <shadow> is defined as:
inset? && [ <offset-x> <offset-y> <blur-radius>? <spread-radius>? <color>? ]

mozilla的这个定义应该更加完整，不仅表现出了多阴影的特性，就连值是什么都写的很清楚。

• 每一个box-shadow属性由一个或一组逗号分隔的<shadow>给出
• 每个<shadow>被定义为下面这些值的组合：
  • inset关键字，将外部投影转变为内部阴影。
  • 第1个长度offset-x代表阴影x轴向的偏移，正值向右，负值向左。
  • 第2个长度offset-y代表阴影y轴向的偏移，正值向下，负值向上。
  • 第3个长度blur-radius代表阴影模糊半径，不允许负值。
  • 第4个长度spread-radius代表阴影扩展半径，正值放大，负值缩小。
  • color代表投影的颜色。

所以通常最简单的调用是这样的：

box-shadow: 5px 5px;

当然这里不讨论浏览器前缀的问题，比如-webkit和-moz。对应到相应浏览器就必须加上各自的前缀。但之所以称box-shadow的支持度高，是基于标准上的完善度和浏览器的广泛度。

• firefox从Gecko 1.9.1（Firefox 3.5）引入此属性的支持，并在FF4最近的更新里去掉了-moz的前缀。
• Opera 10.5 pre-alpha开始支持此标准属性，并且属性前是不需要前缀的。
• Webkit核心是最早实现box-shadow的引擎，所以Safari 3开始就支持了box-shadow。虽然最初的实现上有些bug，不过很快就修复了。
• 同样是Webkit核心的chrome，自然也是支持的。webkit在最初支持的时候并没有附带前缀，但有趣的是，2009年10月，W3c突然将box-shadow 从 CSS Backgrounds and Borders Level 3 里移除了，导致webkit重新引入了这个属性的前缀。所以当前，chrome使用box-shadow是需要前缀的。(更新：最新版的Chrome 10已经移除了前缀)
• 我很欣地看到IE9支持box-shadow......

developer mozilla有一份box-shadow的浏览器支持列表。所以这里讨论时说到 "box-shadow: 5px 5px;" 就是指这样的一种序列：

-moz-box-shadow: 5px 5px;
-webkit-box-shadow: 5px 5px;
box-shadow: 5px 5px;

回到这个最简的例子，实际上 "box-shadow: 5px 5px;" 在chrome里不会有效果，尽管标准定义里颜色是可选的，但是chrome在没有给出颜色的时候和firefox表现不同。也就是说这条规则不是没有生效，只是chrome似乎是表现成透明了。而firefox则会选择使用黑色来生成阴影。

基于这样的原因，我们还是应该直接给定box-shadow的颜色值。下面就是一个最简单的例子：

在不给定颜色时chrome给人的感觉没有任何反应其实还有另外一个原因，那就是一个是否将阴影计算为内容的问题。举个例子，一个宽度100%的div设置偏移x轴50px的阴影，父容器overflow会将这多出来的50px怎样？如果把这个div放在body里结果又会是怎样？答案是chrome完全忽略阴影，而firefox则撑开父元素出现了滚动条。但到底谁的实现更为正确呢？下面会有详细说到。

标准里有一张非常直观的图，描述了box-shadow的工作方式。这张图直观到只要仔细看懂就几乎能明白box-shadow方方面面。

图中可以得到的信息很多。比如圆角、阴影扩展、模糊、内阴影以及padding值是如何影响阴影的。下面是另外的一些细节。

非零值的border-radius将会以相同的作用影响阴影的外形，不过同样是CSS3属性，border-image不影响阴影的外形。

就如同box模型的层次一样，阴影也有属于自己的层次。外阴影绘制在背景之下，内阴影绘制在边框(包括图片边框)之下背景图片之上。众所周知，背景图片的层级在背景颜色之上，所以整个层级关系就是：边框 > 内阴影 > 背景图片 > 背景颜色 > 外阴影 。

根据定义，阴影不会触发滚动条，也不会增加可滚动区的大小。刚才说到chrome完全无视阴影而firefox撑出了滚动条(更新：新Firefox已经修正了这个问题)，现在就这一点而言，似乎webkit显得更为标准。实际上无视阴影也是完全合理的，本来我们就不应该因为阴影样式而造成伪内容影响到布局。

多个阴影以逗号分隔列出的时候，他们从前到后依次被覆盖，定义越前面的阴影有越高的层级，会覆盖在后面定义的阴影之上。如上所述，阴影不影响布局(layout)，并依照层次覆盖其他box及其阴影之上，如下所示：

关于box-shadow，当前就先讨论这么多。还有一些关于标准的东西尚比较零散，等我重新组织后再更新此文。然后下一篇《CSS3 box-shadow 详解(2)》我会详细讲述其应用。

起因是下面的这句话：

font-size: 75%; /* Resets 1em to 11px */

这是我曾经喜欢的wordpress主题 Bito 的第一句CSS。印象里还是记得默认值是16px，那么75%就是12px了。不过这只是表面问题，其实大部分人都不怎么关系字体大小的本质。

从标准看起

W3Cschools的font-size参考相当简单，只是简单的列举了属性的可取值。并且CSS2.1 Specification RC20090908里，关于font-size的定义也并不多。

大体上，font-size的值非常宽泛，即可以是关键词定义的绝对值，可以是百分比或者 em 的相对值，还可以是绝对单位px。在实际工作中，我自己都似乎快习惯于用px定义字体大小，很少使用到那些关键字或者比例，但可能这不是个好习惯。回想自己学习CSS的过程里的例项，大部分都是用em或者百分比的。

关于px

对font-size直接应用px值，这样做非常精确，而且也方便，所以我们习以为常。当对font-size赋予px值意味着浏览器将会把文本渲染成指定的像素那般高。并且通常情况是，西文字符在9px以下、中文字符在12px以下时，文字将难以辨认。使用像素单位的主要问题是两个：

1. 当把文字设定为固定px值后，IE6以下浏览器将不能对其缩放。
2. 固定尺寸后失去级联特性。

老外的眼里，第一点似乎是个大问题，因为他们把网站的可访问性和易用性看的很重，无法看清字几乎是不能容忍的。而第二点，只要不做弹性布局或者设置字体调节器之类的应用，并且针对的只是显示器，也就不是大问题。这恐怕也是导致px这么泛滥的原因。好用，简单，并且最重要的是——精确。

但是对于易用性来说，px似乎不是个好东西。
W3C Web 可访问性指南：在标记语言的属性值和样式表属性值里使用相对单位而不是绝对单位。[...]比如，在CSS里，使用 ‘em’ 或者 百分比长度 而不是使用绝对单位 ‘pt’ 或者 ‘cm’ 。

百分比的使用

百分比和em都是相对值，相对于父元素的字体大小。1em等于1个字体的大小，Chris Coyier认为em是基于大写字母 M 的宽度(除此以外，我找不到更好的参考)。使用百分比和em可以很好使得各个元素间产生级联的比例关系。

鉴于windows的浏览器，默认的字体大小是medium，即 16ppem (后面会讲到)下显示为16px。所以75%就是12px，而62.5%就是10px。

基于font-sizeのパーセント表記一覧里的百分比的零散表格，我重新组织了下面这张整表。下表仅仅作为参考，因为百分比的微弱递减或递增不会对文本产生可视化的效果(当然也有例外)，反而容易产生出混乱的级联百分比关系。

之所以选择了参考了这位日本开发者的资料是有原因的。比如，我们常常全局定义字体的相对medium(通常为16px)的62.5%，也就是10px，然后再对文档的个个其他部分定义em值。相对于10px，1.2em就是12px，1.6em就是16px，依次类推。这样的比例使用起来很直观，并且会在所有的浏览器里表现完好，当然除了IE。

IE会错误的显示字体大小(感觉上是字体框架有细微的变大)，并且仅限于中文。除非我们将比例设置成63%而不是62.5%。所以当我看到这张表中63%的时候，我觉得同是非西欧字符，这张表应该更具有参考价值。不过这些值我也没能自己去全部测试，偷懒一下～

em似乎比百分数更加直观，而且对于一个字体的宽度的把握往往也更容易。同时它们有相同的级联性，使用的时候总是要避免规则的叠加。比如定义 div{font-size:1.2em;} ，那么在div里包含div就会出问题。1.2emx1.2em的叠加会使得文字比想象中的大——但这还不要紧，如果使用的是0.8em？缩小倍率的多次叠加很快会使得文字变得无法分辨。

无论是em还是百分比，都是相对值。并且常常相对于medium。但是关于medium这类关键字，就有了更多的话题。

关键字

我对于font-size的理解一直停留在上面说的那些，直到半个月前，我读到这篇Toward a standard font size interval system。

回到之前的CSS2.1 Specification RC20090908，标准把关键字定义为这样：

下面这张图，更加直观些。但是注意第二行。同样对于English Font加上larger，IE8和FF渲染为18px，Opera、Chrome和Safari则渲染为19px。

下面的表截取自Toward a standard font size interval system里的Synoptic table，对应于windows常用的96dpi的情况。是的，96dpi，我们几乎从来不去改变这个默认的值，除非也许某个人因为高分屏字太小的折磨，而主动调大到了120dpi。

牵扯到一个很重要的概念，ppem。它指的是Pixels per em，即每个字体大小的像素数，定义了字符在屏幕上的易读性。关于更多的信息，我强烈建议阅读Toward a standard font size interval system原文。

当把xp的dpi从96调整到120， 整个系统的尺寸，包括图形和文字都被放大了。此时，如果打开IE，font-size:medium 不再是16px，而是20px。虽然我也试过Chrome和FireFox，但它们没有变化。我不明白原因，如果有人知道，麻烦请告诉我声: ）

这再次的提醒了我们，CSS不是只为显示器而设计的，而且也不是专为windows而设计的。我们有时可能需要考虑更多更多。
水平有限，文中如有错误望指正~

虽然起了一个看似很牛逼的题目，但本文可以说完全是蛋疼的人的一种消遣~通常开发人员都有自己的放松方式。写文章用不了太久，倒是图材准备了老半天。谨以此文，让我们来消遣下各个浏览器对于边框的理解方式。

参与此次测试的浏览器包括windows下的几乎全部：ie6，ie7，ie8，ie9preview，chrome，firefox，safari，opera，seamonkey。各版本皆为网上下载的最新版。并且由于这次的测试里，IE678的表现一致，firefox和seamonkey又是裙带，所以合并作IE8和firefox。下图就是这次浏览器的截图：

上面的这种排列顺序是故意的。下面的测试里就会显示出其原因，截图也都是按照这个顺序排列的。

首先看下面这张图，六种浏览器里显示了一个20X20的DIV，其边框为top:2px，其余1px。似乎没有什么不同。这是由于1px的细微让我们没有在意。(事实上这整个问题我们本来就不需要在意~)

先把问题简单化，单边2px，三边1px，并将结果放大5倍，我们能清楚的看到这种差异——opera和safari相反，ie8缺胳膊少腿，下面三个家伙一致~这里要注意到的是第二行3者在交汇处都有渐进效果。

也许我们该让这种效果变得更加明显。当仅仅加粗单边之后(10px)，IE8的怪癖显露无疑。opera和safari依旧相对。下面3个统一战线的渐进变的更加明显。

假如颠倒下会是怎样？3边加厚，结果是有些出乎意料的。opera的表现很诡异，换句话说，它顶上的那条线，在上面的例子里“优先”了只是一种巧合。IE表现的更加像opera，而不是它缺胳膊少腿的一贯形象。safari贯彻始终，并且，下面三个家伙的结果也是意料之内的。

回到最开始第一幅图的地方。用4种颜色分别画4条边。这里仍旧是放大5倍，现在就能更加清楚的看到IE8的做法。

在边框宽度都相同的情况下，每个浏览器都表现的挺好。对于边框斜角的应用我最早在《Eric Meyer on CSS 1》里看到。这种45度斜角使用上没有危险性，但是其他角度就未必是这样了，特别是用在双线的时候。
这里留意下面三个截图，FF和chrome，ie9的表现是不同的。可以看到渐进的处理方式不相同。chrome和ie9交汇处有白边，但是FF没有。

下面就是双线了，这又出了一个问题，就是ie9的双线是糊的...由于用的是4条等宽边框，其它看起来似乎都不错。

于是，换用一种糟糕点的角度呢？ie8首先不成框样，居然用空隙...感觉上非常粗糙。另外ie9糊的真水...

当我再尝试一些角度时，Opera也出问题了，它的边框显得多余很难看，简直和ie8有的一拼...

当然，本来浏览器对于线型的解释就不同，所以实线之外的，就没有什么参考价值了，这里仅做娱乐~~
dotted之后，尽显衣钵本色。

dashed又如何？同是webkit，表现却并不像刚才的dotted那么相同。ie8依旧很诡异，只有4个点，上下的线消失了...事实上，之所以这里把DIV加长到20x30，是因为，20x20，不够ie8显示这么宽的dashed线型，那4个点也会消失的~

下面就是最有趣的地方了，当DIV的尺寸变成20x40，线宽如图所示，结果，ie8和ie9是可以合体的！！！它们的合体可以组成一个完整的独一无二的solid框！一像素都不差~

当将DIV的尺寸加到的89x39的时候，ie8才完全显示出dashed框，并且此时chrome会突然变得和safari不同。

好了，也算的上是一轮浏览器的探索了。或者说消遣，再或者说无用工。因为没有结论，只有现象，而且还是无用的现象。但仍然希望这能勉强算的上是块砖头，期待高见~