能写文章，说明时间略有空余，这应该算好事吧～看了下草稿箱，果断还是选这篇先写完，因为和前面的几篇有关联。在之前的 圆角响应区 以及 圆角边框和overflow 中，已经讨论过圆角边框的一些问题，本篇如题，是关于圆角边框和 outline 的，这里也正好回答了一丝在圆角响应区里提出的“为什么不在做DEMO的时候用 outline 描画边缘？”的问题。在写那篇之前做DEMO的时候，我是用了 outline 的，但注意到 outline 的一些问题之后，又把它从DEMO里移除了，并起草了这篇文章的标题，然后，一放就是3个月之久...

进入正题，如果同时使用圆角边框 border-radius 以及 outline ，那么 outline 的形状应该是怎么样的？也该是圆角吗？

这个问题看起来简单，本质却复杂。在讨论这个问题前，抛开标准，作为使用这两个属性的人，自己使用之后的期望是怎样的？如果是我，根据以前使用的经验：圆角的圆弧外没有交互区域，既然边框界定了元素，而 outline 又是元素的勾勒，那么 outline 应该跟随边框的圆角。但这未必是正确和准确的，所以这之后我做了部分考证。

先看浏览器(Chrome-24,IE-9,Opera-12,FF20)的表现：所有的 outline 都显示为矩形，无一例外，也就是说没有跟随边框的圆角。这是一个和预料相矛盾的初步印象，也是我刨根问底的原因。下面就从头说起了，期间，会遇到很多连带的问题，既然这一系列文章讨论的是“蛋疼的细节”，所以我还是会花些篇幅探讨它们。

如果对 outline 的定义如果有什么模糊的地方，可以先参考阅读标准 CSS2.1 outline 以及 CSS3 outline。定义的内容很明确，但是也可以肯定，当前通篇没有任何的 outline 和 border-radius 的相互作用的描述。

于是，我简单做了一个DEMO用来描述 outline 的本质。如果你不打算打开多个浏览器查看DEMO，可以看下面这张截图。就结论而言，即使是单独讲 outline ，其在当前浏览器的表现也并不一致：

上图左边是firefox，右边是Chrome，IE和Opera。之所以没有标注浏览器，是因为虽然大体表现成上面两种类型，但细节上还是有差别。比如Chrome在加粗行内元素的 outline 的时候(图中蓝色线)，不同行的衔接处会有断裂。撇去这些细节不说，标准中说“如果元素跨越多行，outline 应当是包围所有元素的最小轮廓(minimum outline)”，所以firefox的实现方式明显是与标准相悖的。

这个例子的另一个目的是为了展示，当内容超出容器之后，容器的 outline 是否应该包括超出的部分？图中红色的框代表容器，定高定宽，所以内容顶出容器可见。这时，容器的 outline (绿色)也分为两种情况，firefox展示为包含超出内容，其他浏览器则不包含。当然，firefox虽然包含，也并非是期待中最小包含。

这里存在浏览器存在分歧其实也并非什么问题，因为 outline毕竟定义于 CSS User Interface Module，部分定义的模糊也是故意为之，这给了UA更多的在界面上的自由。可以说 outline 这个东西本身就存在不确定性，所以，一旦和圆角边框作用在一起，还能有是非对错嘛？

就如同定义没有给出 outline 的层叠关系一样，定义同样没有给出圆角边框下 outline 应该如何表现，区别是，前者明确指出“不定义”，后者完全是没有提及。但这不妨碍浏览器的自作主张，比如firefox存在私有属性 -moz-outline-radius，可以直接手动控制outline的圆角值。不过，这个值的支持在后续版本可能被移除，跟着这个 2年多前的Bug 593717(- remove -moz-outline-radius and make outlines follow border-radius) 找到的当时w3c的讨论：css3-background: border-radius and outlines。有趣的是，读完这个讨论可以得知，4年前就有人在webkit提议实现firefox已经实现的 outline-radius (Bug 25293)。

回到最初的问题，圆角边框下 outline 应该如何？因为没有明确定义的关系，正确与否并不重要，重要是的在使用任何一种东西的时候，使用者期望它是怎么样的。标准本身是一个描述，一个游戏规则，同时，也是一个多数人的期望的集合。于我而言，我仍然希望 outline 跟着边框绘制，用来勾勒一个实际元素的轮廓，而不是一个box。同时也认为 outline-radius 是没有必要的。

更实际的问题，当前 outline 被绘制成box的情况下，大多数情况下是可以使用 box-shadow 代替的，至少目前为止 box-shadow 跟随 border-radius 比较完美。

结束语

border-radius 话题到这里就差不多结束了，最后顺便一提，还记得 rogerjohansson 写过一篇 Fieldset, legend, border-radius and box-shadow，讲述了一些有趣问题，没看过的朋友不妨瞅瞅。 另外，这里哪里写的不好的，欢迎吐槽。

border-radius 从刚诞生时连背景都包不住的窘境，到现在被广泛使用，这种跃进虽然发生的如此之慢，但它确实实实在在地发生着，作为一个技术观众，我能做的就是记录下它蛋疼的成长，并在十年之后回想起时，付之一笑:)

本篇是上篇《那些CSS的细节问题(2) —— 圆角响应区》的一个简短的延续，因为在上篇的篇幅里实在已经容不下更多混乱的部分。

尽管现在圆角边框的教材已经烂了大街到处都是，并且这个属性已经是诸多CSS3属性里应用最为广泛的特性之一，但却丝毫无法掩盖这个属性一路走来的坎坷。时至今日，现代浏览器对圆角边框的解释仍然存在诸多问题，比如上篇那些CSS的细节问题(2) —— 圆角响应区 讲到的对“响应区”影响的问题，实则也只是这个属性一路而来的问题之一而已。因为，单看一个属性确实很明了——无论是定义还是实际实现起来，然而，一旦这个属性和其他属性作用在一起，事情就没这么简单了。

下文中的内容，皆以如下版本的浏览器为基准：Chrome-24，IE-9，Firefox-18，Opera-12.12，safari-5.1.7。

回到标题，这里主要讨论的就是圆角边框 border-radius 和 overflow 作用在一起时产生的一些问题。为此，我做了一个简单的 DEMO。你可以用不同的浏览器访问查看显示的效果，并查看源代码直接获知这个DEMO究竟在表达什么——虽然说起来也不复杂：就是在一个圆角div上添加各种不同的 overflow 值，内容和边界会表现成什么样？如果你懒得打开浏览器逐个查看，下面就是各种结果的截图(好吧，让我们忽略Safari吧~单单Chrome已经够我们受的了)：

Opera是可悲的，它无法藏主被超出的内容。其实早期不止是Opera存在这样的问题，border-radius 对 overflow:hidden; 无效的bug(459144)以前也一样存在于 Firefox 里，不过现在已经被修复，只是Opera的动作似乎稍慢了。

整张图里，一眼望去最为奇葩的就是Firefox了，当border-radius和overflow的滚动条同时出现的时候，它居然是这样的一个形状！而这次行为一致的居然是Chrome 和 IE... 如果是你，你觉得当滚动条出现的时候应该是怎么样的？我觉得吧，应该是类似Chrome和IE9的那样，但由于没能考证到什么定义依据，所以也不敢确定。请确切知道的朋友告诉我一声～

最后一列 overflow:hidden; + position:relative; 似乎显得有些多余，其实不然。在我草拟这篇文章的时候，webkit存在一个bug（50072），就是设置 position 为非 static 值以及 overflow:hidden; 时，浏览器无法正确隐藏超界的内容。如果你使用低版本Chrome就能在DEMO页看到这个现象。当然现在，似乎这个bug已经被修复了，这也从侧面说明了我这篇东西其实拖了很久...

下一个问题，所有的浏览器在实现 border-radius 和 overflow:hidden; 的时候，和常规的矩形box的并不相同，我个人认为这是实现上的错误。众所周知，在矩形overflow:hidden; 的情况下，我们无法用鼠标选取被隐藏的超出部分的内容文本，但是，如果是 border-radius 曲面隐藏的话，情况就不同了。在白色边角上用鼠标拖动，都可以选中那些看不见的文字。但是，当你保持所有属性不变，单单去掉border-radius的瞬间，所有的这些看不见的文字回复到了正常的 overflow:hidden; 的状态——它们无法被选中。换句话说：所有的浏览器，在实现border-radius 和 overflow:hidden; 共同作用的时候，都只是视觉上隐藏了文本，文本仍然有交互，即使那是曲面外的部分——理应没有任何的交互和响应。

这篇就差不多完了，文中如有任何错误，欢迎各路吐槽。下篇《那些CSS的细节问题》，还是接着说圆角边框...有空就抓紧写，没空的话还得在磨叽一段时间...

参考资料

1. overflow:hidden, border-radius and position:absolute by Philip Tellis
2. Rounded corners fail to cut off content in webkit browsers if position:relative

之前《那些CSS/JavaScript的细节问题》我都是凑足3个再开始写，现在发觉，很多时候要凑出3个古里古怪的问题还真不是件易事~ 有的时候想到要写一个问题，想等凑多些再写，但又总是一直拖着，好端端的讨论话题都过期了。更糟糕的是，往往好不容易凑足了数量，结果之前要写的东西居然又模糊不清了...以后，在一定时间里凑不出数量的话，也只好先写起来再说:)

所以今天，就只有一个问题，关于边框圆角：圆角边框是否影响元素的响应区域？

想象一下，一个 div 通常被我们认知为一个盒子(box)，现在在它的周围有一个圆角边框，那么在这个矩形盒子的四个角上，必然会出现一些空隙（特别是当这个圆角矩形变成一个圆时候）。那么对于这个元素而言，那些空隙还是不是元素的一部分？

换个方式问，元素的响应区域，到底是原始盒模型的矩形区域，还是圆角边框所构成的圆形区域？当然，如果浏览器表现都一样，我恐怕也就不会提这种问题了。

具体情况如何，我们还是直接问浏览器吧！为了方便比对，最简单的方法就是用 :hover 伪类看鼠标的状态变化。我做了一个简单的 DEMO，你可以用不同浏览器查看结果。当然如果你懒得看的话，下面就是这个DEMO的两种结果：

• 左边，响应区与圆角无关，鼠标状态在初始的box的范围里全都有变化。浏览器包括Chrome，Safari，Opera。
• 右边，圆角外围的部分无响应，仅仅只有边框内部区域有效。但如果内部包含内容，并且内容在边框之外的话，也一样有效。浏览器包括Firefox，IE9

我测试使用的都是最新的浏览器，FF-17，Chrome-23，IE-9(很遗憾身边没有IE-10)，Opera-12，Safari-5，现在，该相信谁呢？还是说，它们一个都不对？

如果是平常，我一定优先考虑Chrome和Firefox的结果，问题是，它们站在了对立面上。但就结果而言，我可能更容易接受Firefox的做法：以边框为界，圆角外的区域应当不作响应。试想，我总不能画一个圆而让这个圆的不可见的外接矩形作为交互区域吧？这多别扭！

既然浏览器各执一词，那就只能翻翻游戏规则了。没想到，W3C标准里居然非常明确地写明了这种情况：

Also, the area outside the curve of the border edge does not accept pointer events on behalf of the element.

呵呵，Chrome你个混球！看看你都干了神马！还把 Opera 也一起拖下水，Good Job～好欢乐啊～

水落石出了，换句话讲，border-radius 是会缩减响应区的，其圆角曲线外的那些空白区域是没有交互和响应的。也正因为此，标准特别提醒要作者注意圆角边框的元素的交互尺寸。而任何在在做怪应用而遇到这个问题的人，也完全不必去理会 Chrome 和 Opera，因为，这次真相掌握在了IE和Firefox手中！

PS：下篇那些CSS的细节问题，还是讲圆角，更加蛋疼的圆角麻烦问题还在后面呢～

参考资料

1. CSS Backgrounds and Borders Module Level 3 - 5.3. Corner Clipping from W3C
2. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification - 8.1 Box dimensions from W3C
3. CSS Reference border-radius from MDN
4. CSS Reference background-clip from MDN

响应式Web设计(Responsive Web Design – RWD)一般是指那些使用CSS3 Media Query特性制作站点，其可以适应不同视窗尺寸的布局。

虽然很早就已经有了类似RWD的概念，但直到最近一年里才开始变得特别流行，各种文章、例子、工具、模板，不断地从无到有，诸如：

• 响应式Web设计50个例子和最佳实践
• 21个响应式Web设计工具
• 响应式Web设计的模板和框架

这些资源，仿佛都是一下子冒出来似的…这要归功于IE9的发布，从而使得主流浏览器上升到全部支持Media Query的程度。

然而眼花缭乱的资料堆里，可供细细品读的资料其实也就那么几篇：ETHAN MARCOTTE 的 Responsive Web Design，以及其引用的 JOHN ALLSOPP 的 A Dao of Web Design。

无论是在UX角度还是维护角度，RWD的优势都显而易见。虽然很多移动设备都默认就可以缩放页面，但是RWD就意味着最少的缩放，最少的滚动，最少的用户行为。我们不必要求用户拨动他们的手指来调整页面的舒适度，因为这种舒适度是我们一开始就设计好的。

作为设计师，RWD算得上是一种限制，甚至一些设计的权利已经被前端所剥夺。为了达到良好的自适应效果，很多设计点上不得不做出偏向代码的妥协。所以可能单纯的视觉设计师可能并不喜欢RWD。然而对于前端来说，RWD非常迷人：一处代码，却处处不同。开发人员只要开发维护一个版本，就能使页面在不同的设备里均呈现良好的访问性效果，何乐而不为？

一旦牵着到RWD，就不可避免的使得页面设计本身趋向相似。看看那些RWD的页面就会发现，很容找出他们的共同点：流式的布局、网格化的排布以及相对而言死板的布局。之所以如此，是因为对于RWD而言，流体图片(Fluid Images)和流体网格(Fluid Grids)是必须，完善的RWD视觉设计里必须以它们为限制。

而随着RWD的各种或浅或深的应用，一些非常常见的IE trick的弊端也开始显现。

比如，IE低版本的“浮动双倍边距bug”是如此常见，以至于我们几乎是可以闭着眼睛在浮动元素上添加 display:inline; 来触发IE的haslayout来修正。由于浮动元素独自成块并构建自己的块格式化上下文，所以这句 display:inline; 的有无对现代浏览器来说毫无影响。当然问题也就随之而来，在 Media Query 里仅仅取消这个元素的浮动是不够的，还需要同时将 display 置回 block。即使是经验丰富的人也可能在这里浪费一些时间，因为他们可能意识不到一个长久写惯的trick会在这时候捅你一刀。

最后，虽然RWD如此流行并且是个好东西，不过对于Web而言也并非必须。网站依据自身特点可以酌情引入部分这种功能，以此来改善移动设备的浏览体验，毕竟有些站点本身就不适合做RWD的考量。

人一旦被一些繁杂的事消耗掉精力的话，即使有时间静下心来写篇东西也变得那么的不易啊，呵呵。题外话就不多说了，真没想到这篇早就构思好的东西写了这么久...

阅读本文请使用chrome，Opera或者FireFox浏览(23 December 2013: 由于迁移到ghost，其早期版本对HTML的支持不够理想，所以迁移过程中将所有HTML例子切成了图片)

在上一篇的CSS3 box-shadow 详解(1)里，我从标准的角度出发，详细地写到了box-shadow的标准的方方面面。但毕竟是游戏规则似的细节，读起来恐怕还是没什么味道，按照上次的安排，这篇里不再牵扯标准的任何细节性的东西，主要就是讲实际应用中，box-shadow能做些什么。

设计中的阴影

对于设计来说，阴影的重要性和颜色等同。视觉要表达的是“光”的美的规则，任何视觉归结到底是光的艺术。当然，有光就有影。要表现空间和层次，通常的做法无非就是这3种：阴影、渐变和透视图。这三者是让网页脱离平面化而表现出层次的常用手法。

现在流行的设计里总是使用了大量的阴影，看看Vista、win7里夸张的box阴影，mac里的阴影比比皆是。box-shadow赋予了我们阴影样式，使得我们可以不再总是依赖于图片的使用。当然box-shadow最为常用的做法就是“当做阴影”来使用，但它的用法却远不止如此，甚至还能“管些其他样式的闲事”。虽然我不推荐box-shadow做太多越权的事，但在当前有些属性还不完善的情况下，box-shadow的良好支持不失为一种解决途径。

阴影

当然它本来就是阴影:) 。我们可以为网页元素中的任意的box添加视觉上的阴影表现，这正是box-shadow本来要做的。

虽然基于标题“详解”二字我很想写的更全面些，但是对于box-shadow阴影层面上的使用，我还是决定略过。这方面的使用可以参考css3.info上的 Box-shadow, CSS3中最好的新特性之一(可能有时被墙)。其它国内的关于box-shadow的阴影使用的文章也已经相当的多了，所以这里就不再多说了。 因为这是box-shadow最基本使用方法，并没有什么特殊之处。

边框

除了把阴影用作阴影以外，我们还能拿它做什么？由于box-shadow拥有扩展半径这个值，使得阴影具备了充当边框的能力。看看下面的阴影模拟的边框：

实际上，用阴影充当边框，其效果是似边框而非边框，阴影充当边框和真正的CSS边框有着本质的不同。如果你的眼力够强悍，应该是可以看出上面两者的不同的——虽然他们的尺寸完全相同外表也毫无新差别，但是左边的box要比右边的低那么一点点，是的，一个像素。

当我们加粗边框之后，这种表现就变得异常明显：

这和我们之前讲的阴影不影响布局的结论不谋而合——虽然边框被计算了宽度，但浏览器忽略阴影。因为这个特点，阴影所模拟的边框可以更加自由的使用，当然必须注意层级关系和覆盖。并且恰恰是因为可以覆盖，所以在没有绝对和相对定位的情况下，在普通流中，都可以将边框叠加！

事实上，阴影创造出的边框远不止如此。我在前篇多次提到的“多阴影”，在实现边框上也是大有作用。

多阴影不仅仅使得阴影可以模拟多多层边框的情况，更重要的是，配合box-shadow的扩展半径，我们更是能造出单层的多色边框。或者在边框上加上什么修饰也变得异常简单。

所以借助于box-shadow，我们可以模拟出许多种曾经让人皱眉头的边框，当然这是有限定的，并且适用面其实并不大。但是当我们恰当的使用的时候，仍然有突出的效果。同样，使用box-shadow作边框有很多要注意的地方。注意使用时的层级关系（前篇有详细讲过），防止阴影出乎意料外的覆盖（毕竟其不影响布局），最后就是要考虑到阴影的大小始终是跟着box的高宽的，所以box宽高宽变化必须被考虑在内。实际上box-shadow的边框同样有相当好的自适应效果，但同时可能自适应出来的效果并不是设计者所希望的那样。

好了，关于伪造边框的使用就写到这里。其实box-shadow对于边框发挥余地还是相当大的，配合模糊、扩展半径和多阴影这几个关键要素，我相信还能够伪造出更加有趣的边框。为了引出下面的一个标题，我们看看下面这个多阴影的例子：

将一个多阴影边框模糊后的对比效果如上面的左右所示——模糊了30px。模糊意味着边界的不明显，这其实和一个概念很相近——渐变。如果你看到了边框各个边框因为模糊而融合在一起，那么这正是下面所要讲的内容。

渐变

如果你是一位设计师，一定不难理解模糊和渐变的裙带关系，这就是我们最后要利用模糊的原因。box-shadow的模糊值，我们可以利用这个值伪造渐变效果。

也许你要问为什么不使用CSS3的渐变呢？这有两个原因：其一，各个浏览器对于渐变的支持的使用方法上，差别较大。其二，伪造渐变和伪造边框一样，在特定场景下是有用的。所以用box-shadow伪造渐变是有价值的。

不幸的是，现代浏览器对于模糊的支持上仍然是有所不同的。由于W3C虽然定义了box-shadow的各个值，但是却并没有限定box-shadow的模糊所使用的算法，这就直接导致了各浏览器之间的差别。在这点上，Firefox显然要高明些，它的模糊算法非常平滑，是完全可以当做渐变来使用的。然后是Opera，表现的一样不错，至少从Opera11（因为在我的印象里Opera10的表现也很一般，改天再看下）开始它的模糊算法也比较平滑。Chrome以及Safari相对来说，表现的都非常一般，在模糊的边缘是有些生硬的，甚至都能看到棱角...囧。(更新：Chrome 15 已经解决了模糊算法的问题)

下面是一个直观的比较，用的就是刚才上面的那个效果，差异是显而易见的：

然而差异如此，把box-shadow用在表现简单渐变上也已经是足够的了。多阴影、内阴影、扩展半径以及模糊这四个点，已经使box-shadow具备了渐变的基本能力。

下面就是两个最简单的例子：

当然，限于模糊算法，模拟的渐变跨度并不能太大。左右渐变已经非常明显的变得很“不线性”，并且这种情况在chrome下会变得更加的明显。换言之，这种模拟的渐变可能比较适合用在按钮、tab标签等小件的上下渐变上。

其实我博客的自己的主题里是大量使用了box-shadow的(现在的主题已经换过了，已经移除了大部分阴影)(23 December 2013: 迁移到Ghost之后暂时用默认主题)。但大部分都是非常浅的#ccc甚至是#eee这种非常弱的灰色调。因为本来自己的主题就是各种色调的灰线和非常淡的灰色块。举个box-shadow使用上的例子，我觉得自己的导航上的tab标签会比较适合：

单单一个tab标签上，我就用了4个阴影，一个用来投射阴影，一个用来制造底色渐变，一个用做白色的勾线渐变，最后的字体的白色阴影则是制造雕刻的立体感。不过，一切都是那么的淡，所以几乎是看不出来的。但是我仍然相信，在灰度表现较好的显示器上，这点想法还是多少能够表现出来的。我不敢说它有多美观，甚至甚少有人能看出用了多少阴影，但我觉得这么淡足够了，毕竟这是细节，丰富的它的时候拘泥其中，但是一旦作为一个主体的一小部分，是可以完全忽略的。

#top-nav ul li{
	float:left;
	margin:0 0.5em 0 0;padding:0;
	-webkit-box-shadow:0px 0px 6px #eee;
	-moz-box-shadow:0px 0px 6px #eee;
	box-shadow:0px 0px 6px #eee;
}
#top-nav ul li a{
	display:block;
	background-color:#f9f9f9;
	padding:0.2em 0.8em;
	text-shadow: #fff 0px 1px 0px;
	border-top:1px solid #999;
	border-left:1px solid #999;
	border-right:1px solid #999;
	-webkit-box-shadow:inset 0px -7px 15px -7px #dfdfdf, inset 0px 0px 0px 1px #fff;
	-moz-box-shadow:inset 0px -7px 15px -7px #dfdfdf, inset 0px 0px 0px 1px #fff;
	box-shadow:inset 0px -7px 15px -7px #dfdfdf, inset 0px 0px 0px 1px #fff;
}

虽然大费周章的用CSS做这些PS只需瞬间完成的事确实非常蛋疼，就像CSS3一开始人们热衷于用圆角和渐变绘制各种图标一样显得有些毫无意义。这些都是事实。但仅仅因为如此而放弃对于新特性的探索，也绝对是蛋疼的。

总结就不写了，只是没想到这篇文章写这么久(笑)。匆匆成文，写错的地方还请各位随意指出。

扩展阅读

• http://www.w3.org/TR/css3-background/#the-box-shadow

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

前段时间看到一篇《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)》我会详细讲述其应用。