鼠标中键的点击的行为默认情况下，通常是创建新的tab并在其中打开指定的链接。浏览器发展到今天，对于鼠标中键点击的事件处理上，仍然没有能够统一，这导致对应于中键的监听变得不可靠，而对于习惯用中键的用户来说，点击某些链接会出现意料之外的结果。

下面对现行浏览器的一般表现做一些总结，浏览器分别为：IE9， FF31，Chrome36以及Opera的Presto内核的末代版本12.17，本文结果均以这些版本为限。

测试代码很简单，由于各浏览器对于鼠标键位的索引值也有些许不同，所以用了jQuery来统一。<a>中的<span>是故意添加的，下文会有说明。

<a href="http://swordair.com" id="link">click <span>here</span></a>

$("#link").on('onclick', function(e) { 
    alert(e.which);
});

首先说一下已经作古的Presto：中键点击事件在任何情况下都是被忽略的，当中键点击一个链接时，Opera打开一个新的tab并加载目标URL的内容。这样的做法虽然很一刀切，但也因此少了很多歧义。中键的作用变得非常直观，但随着Presto的消逝，我们也就少了一种最直观的处理的观点。

Opera是个特例，写出来只是提供多一种思路。现行浏览器对于中键点击的处理并不像Opera这么干脆。

所有浏览器都能完整捕获和处理除了onclick以外的，诸如onmousedown，onmouseup事件，而唯独对onclick事件英雄所见不同。

Firefox对于中键点击的处理上，唯独onclick事件只能在document或window上冒泡获取，而无法在元素上直接触发。中键onclick的表现上，Firefox的做法可能更为灵活。对于用户来说，中键的行为是直观的。对开发者来说，却又没有将路堵死。

IE的表现很有趣，当点击的目标是一个链接时，IE忽略了onclick，直接新建了tab打开了新页面。但当点击目标不是链接，甚至，即便只是链接的子元素，IE都会180度转变直接触发onclick。这也是为什么之前的测试代码里，click here的一部分被放在了span里的原因。IE的做法其实很小聪明，在绝大部分应用环境里，行为表现都更为合理。但相对不统一的处理方式，对开发一方造成困扰。

最后就是Chrome了，代表的是blink/webkit。遗憾的是，Chrome的做法也是一刀切，但比起Opera对于默认行为的遵从，Chrome的做法显然不怎么优雅。Chrome触发中键的onclick，并且无论目标是否是一个链接。这造成的问题是，如果用户习惯使用中键打开新页面，而链接上恰巧又带了相应函数，那么最后的结果可能就是用户期望之外的：

<a href="http://swordair.com" onclick="gotoOtherLink()">link</a>

总结以上，就是Opera最为干脆，Firefox最为温和，IE最为小聪明，Chrome最为笨拙。末了，在为Presto默哀几秒...

所以在网页中对中键的控制是非常不可靠的，好在我们使用上也不是很频繁。唯独在网页游戏这一块，由于可能需要用到中键的功能，中键的onclick可能会变成一个比较纠结的问题:)

这段时间前端界的头条大新闻无疑是“Opera即将逐步放弃自己的Presto核心转而采用Webkit”，虽然之前的新闻还只是Opera在移动浏览器上使用Webkit，但一旦变成桌面也一样的情况，立刻就成了一颗重磅炸弹，粉碎了这个领域里虚伪的和平。Webkit几乎垄断了移动浏览器市场，现在，似乎也即将称霸桌面。欢喜者似乎幻视到了一个统一的标准的平台恍然在眼前招手，担心者回顾过往揣测着眼前的巨兽仿佛看到了IE6，各种评论在各个论坛炸开了锅，各种声音削尖了脑袋此起彼伏，就好象是迎接三国鼎立时代的序幕一般。哦！壮哉，我大Opera，壮哉，我大Presto。如同一颗晖星从天划过，标志着一个时代的终结，和另一个时代的开幕。

可能所有人都没想到这样的结局，如果说，在移动领域采用webkit是鉴于其霸主地位的无奈之举，那桌面端的全面缴械几乎意味着Opera对于Webkit的认同。一个存在快要20年的浏览器内核所走就走了，简直是难以置信。但确是事实，2013年2月12日，世上最独特的自有内核浏览器——Opera，其官方博客发布了这则消息，标题为：300 million users and move to WebKit，这样一篇意义非凡的文章我还是耐心地看完了，包括文章下面的诸多评论——有人说这是明智的决定，也有人说要告别Opera，其实最无法接受这个事实的，应该还是那些坚持使用Opera的用户，他们担心Opera就此依附于Google，甚至有人觉得，比起选择Webkit，还不如选Gecko。

Bruce Lawson 陈述里，对更换内核给出了下面这样解释：

When we first began, back in 1995, we had to roll our own rendering engine in order to compete against the Netscape and Internet Explorer to drive web standards, and thus the web forward. When we started the spec that is now called “HTML5″, our goal was a specification that would greatly enhance interoperability across the web.

The WebKit project now has the kind of standards support that we could only dream of when our work began. Instead of tying up resources duplicating what’s already implemented in WebKit, we can focus on innovation to make a better browser. Opera innovations such as tabbed browsing, Speed Dial and data-saving compression that speeds up page-load, have been widely copied and improved the web for all.

随后，我看到 css3.info 发文称 Bruce Lawson 在其自己的博客里陈述了更多原因：

Opera’s Presto engine was a means to an end; a means for a small, European browser company to challenge the dominance of companies who, at that time, hoped to “win” the web through embracing, extending and extinguishing web standards.
Presto showed that it was possible to make a better browser while supporting standards. Other vendors have followed this path; the world has changed.
These days, web standards aren’t a differentiator between browsers. Excellent standards support is a given in modern browsers. Attempting to compete on standards support is like opening a restaurant and putting a sign in the window saying “All our chefs wash their hands before handling food”.
Rendering engines are now highly interoperable – largely due to the progress commonly known as “HTML5″, begun by Opera in 2004, then joined by Mozilla, in order to protect the web from proprietary platforms, keep it open and promote interoperability.
It seems to me that WebKit simply isn’t the same as the competitors against which we fought, and its level of standards support and pace of development match those that Opera aspires to.

Presto已功成身退，给我的是这样一种感觉，淡淡的哀伤和深深的遗憾。Presto完成了开创Web标准的使命，如今，Opera将不再重复Webkit已经实现的功能，做重复造轮子的事，而是把精力放在浏览器体验上。此时此刻，恐怕是Mozilla的心里最不好受了。

早前，W3c就webkit前缀的问题已经有过一番争论，这次的事件再一次将这种Webkit威胁论推到了风口浪尖。就像OnePiece里的四皇一样，4大核心一直维持着一种微妙的平衡，现在的这种失衡在真正达到三足鼎立的新平衡之前，会彻底改变整个浏览器的格局，尽管Opera的市场份额几乎可以忽略，但是它近20年的历史影响力足够让人为它的落幕扼腕叹息。

我不是Opera的忠实用户，但作为一个前端其实仍然希望看到浏览器的百花齐放——尽管是怀揣着众所周知的矛盾。Webkit虽如日中天但也暗流涌动，Mozilla身上的担子更重了，IE的日子更难受了。而身处于这样浏览器乱世，作为前端还是该干嘛干嘛吧...就如同Opera所说的那样：

Keep coding to the standards, not to individual rendering engines; test across browsers - Opera, Firefox, Chrome, Safari and Internet Explorer; use all vendor prefixes and an unprefixed form in your CSS and JavaScript.

Web需要标准，但任何一个内核和浏览器都不是标准，它们为标准所用，却都不应单独主导标准。无论是曾经的Trident，还是现在的Webkit，当前它们不仅不是标准，未来，我们还得防止它们成为标准。

Opera，为Web标准化贡献了太多太多，终究还是英雄迟暮。别了，Presto。

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

阅读本文请使用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)》我会详细讲述其应用。

起因是下面的这句话：

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不同。

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