CSSer对text-overflow肯定是非常熟悉的，并且，对于单行文本的截断，包含了text-overflow: ellipsis;的这3行代码，可能也是我们最为惯用的。

text-overflow: ellipsis;
overflow: hidden;
white-space: nowrap;

这小段CSS甚至兼容至IE6，毕竟text-overflow: ellipsis;原本就是IE的专属，于是早期文本截断的抗争主要是在Firefox上，直到Firefox7.0，我们才抛开对于FF的伎俩而专注使用这段代码。当然多行截断还是没戏，在一些跨浏览器兼容要求较高的场合，前端一度需要后端帮忙截断内容。

虽然也不是没有其他方式实现多行的文本截断，但对于当时的浏览器形式而言不可能全部照顾到位。比如现在可以用伪元素:after定位在多行的结尾，并施加一个渐变过渡来模拟截断。

.clamp{
  height: 3 .6em;
  line-height: 1.2em;
  overflow: hidden;
  position: relative;
}
.clamp:after{
  content: "...";
  position: absolute;
  right: 0;
  bottom: 0;
  background: linear-gradient(to right, rgba(255, 255, 255, 0), #FFFFFF 50%) repeat scroll 0 0 rgba(0, 0, 0, 0);
}

渐变的使用让截断看起来不那么生硬，不过我一次都没在实际场合用过:),因为这种方式有很多弊端，而且我也向来不喜欢用这种看起来就很丑陋的方式。除非被逼急了，不然我总是对一本正经地对别人说：“臣妾做不到”~

如果单单是webkit，通常的做法就是-webkit-line-clamp，对于目前webkit所主宰的手机端还算是比较好的方式，效果也正是我们所期望的那样：

display: -webkit-box;
-webkit-line-clamp: 3;
-webkit-box-orient: vertical;
overflow: hidden;

好多年了(>5)，这段代码还是工作良好，不过现在回过头看看，-webkit-box是旧的flex的语法，虽然现在和新flex语法并存，但指不定哪天就没了呢。但即便如此，也并没有更好的办法，没有替代-webkit-line-clamp的属性，新旧语法也无法混用，我们只好继续乖乖使用“经典”代码。

-webkit-line-clamp存在另一个小问题，就是对中文的支持有瑕疵。相比英文下的完美效果，使用中文时，随着容器宽度的变化，截断的那三个点"..."往往会抽风，只显示2个点甚至是1个点，希望更新版的浏览器可以搞定这个小问题。

在文本截断时，我们总是习惯默认用三个点来表示，实际上除了上面提到的伪元素模拟的方式外，我们也无法更改这种表现形式。不过，回过头来再看一下text-overflow这个属性，新版的标准会带来的更多的可能性。

CSS Basic User Interface Module Level 3目前是CR的状态，text-overflow只有两个值可选：clip 或者 ellipsis，不过到了草案中的Level 4，属性值变得更多：

[ clip | ellipsis | <string> | fade | <fade()> ]{1,2}

我们可以指定<string>文本来替换截断时万年不变的那三个点，可以指定过渡和控制其距离，甚至可以提供两个值来同时控制行首与行尾...虽然这似乎并没有什么卵用，但Firefox居然早在9.0就首先支持了其中的<string>值和双值语法！我擦，莫非是当年Firefox在text-overflow遭人诟病后，痛改前非一步就迈向最新的坑里去了么...

然而，text-overflow还是那个text-overflow，依旧是单行，依旧是配合老搭档white-space: nowrap;,还是那个熟悉的味道。纵然可能多了些时髦的功能，却依旧无法掩盖我们在多行截断上的手段之匮乏。

本文完。

十年前，当百度空间在06年7月正式上线的时候，我写了自己的第一行CSS样式。我清楚地记得那是一行指定百度空间background图片的代码。而CSS就是这么简单的东西，一个刚入大学的学生，只是希望为自己的空间稍稍装点一下而单凭猜测和模仿就能够写上几句的代码。百度空间在运行八年后正式关闭，而自己也决然不会想到，十年之后自己依旧在写CSS并以此度日。

CSS理应是简单的东西，它就是这么被设计出来的“简单的描述”，只是这十年里的前5年IE6的存在俨然使其成为梦魇，而后5年却又随着各种新兴扩展而变得越加复杂。如今的CSS已经不再是当初的设计中“设计师能够控制的东西”，复杂的布局，精巧的维护结构，各种框架，动画过渡...好在IE67时代已经过去，现在我们只需要将注意力集中在CSS本身而非各种hack技巧。

读的第一本关于CSS的书是《Eric Meyer谈CSS》，共2卷，以现在的眼光看来，是一本浅的过头的手把手的教程。之后读了《精通CSS》，毫无疑问是当时最好的CSS的书籍，薄薄的一本框架却异常清晰，虽然翻译上有诸多错误存在。我的书柜里有将近20本关于JavaScript的书，但关于CSS的就只有这3本。那个时代，W3C标准和大批量的IEhack混杂在一起，大量的博客内容都是如何和奇葩的IE战斗的经历，使得修满CSS的技能是需要扎扎实实点滴积累的。记得自己还有在一个代码片段的网站上不停的翻阅CSS的过程，看了2千多段，有很多重复的点，虽然在现在已一无所用，但在当时着实留下了稳健的脚印。

10年过去了，很多事情发生了变化。自己明显不再喜欢扣CSS的细节，关注面往怎么维护怎么开发怎么效率上走了。对于相当多的细节都只保留了一个简单的轮廓，这从近3年的博文里可以反映出来，很少再长篇大论，好多都只是有感而发，比如遇到一个什么破事，上来写两句吐槽吐槽。要是10年前，对着一个新的CSS单位都能写个1000字，现在恐怕就一句话，这货是啥，最多伴随一句，这货咋用...

十年可以改变很多人和事。曾经重视的东西，如今可能一文不值。曾经轻视的东西，却反而是最放不下的。如果我的网站可以再运行10年，那么，下个十年再见！

最后感谢我成长道路上的大师们：Chris Coyier，Eric Meyer，Paul Irish，Nicolas Gallagher，Peter-Paul Koch，Roger Johansson。

在之前一篇一个IE8的新起点中，我简单列举了一些当前放开枷锁的CSS，其中之一就是伪元素。当然，在使用伪元素的时候依旧会遇到一些问题，我总结了一些，简单陈述，留个印象，那么当再次遇到的时候能够有所回想。

使用伪元素主要遇到的问题集中在IE8，因为IE8只是部分支持伪元素。首先，IE8中设置伪元素的z-index可能无效。这点广为人知，在使用伪元素制作冒泡箭头的时候会遇到，无法通过调节z-index使before置于after之上。

另一个较为常见的问题是，无法以类名触发伪元素content的重绘。如果使用过字体图标那么多半遇到过这个问题。因为大部分字体图标是通过伪元素content插入字符而成，比如在一个当前激活的导航里项上添加.active时，看到图标依旧保持着原来的颜色。其实这个不只是IE8会遇到，移动版Safari同样存在这个问题(偶发)，明明更新了类名，外观却不发生重绘。

另外，使用:hover:after以及:hover:before之前必须申明:hover状态也算是一个IE8中的使用事项。

IE8后续的一些版本同样存在一些关于伪元素的bug，比如，rem单位无法作用于伪元素的行高。这个影响不算很大，最多看到一些行距错位，百思不得其解最后发现原来是rem和伪元素搞的鬼:)

当然Firefox也无法幸免，即使是最新版本的Firefox中，伪元素:before绝对定位出现在浮动的子元素之后，这个行为有点不太符合预期。因为尚且无法找到对应的标准描述，我只是觉得IE和Chrome的做法更符合我的预期罢了。

另外一提，chrome的早期版本(<25)，伪元素不支持动画过渡。当然这个点已经是一个过去式了。最后，filter滤镜无效。

都是凭借记忆写的个人谈，可能存在些微纰漏不要怪我:)

随着新版本浏览器不断的更新，相信伪元素的问题终有一天可以到忽略不计的程度。而且即便是现在，我们也是很欢乐地在使用着。毕竟，不是人人像我这么倒霉碰上这么多杂七杂八的问题嘛～

前段时候有个朋友问我rem需要注意些什么，我回她说这个参考网上一搜一大把。因为如果我没有记错2011年左右这个rem的单位就已经被各大技术博客讨论的铺天盖地。而现在已经快2016年了，不得不感慨时间的流逝。曾经的IE6已经消亡，虽然过程缓慢，但相信IE8最终也会和IE6一样成为历史。到了那个时候，rem就可以真正走上历史舞台了。如是，我觉得自己还是有必要拿rem出来写一写，一来证明一下我这个博客只是诈尸，二来对当前可能没人讨论到的方面做一个补充。不过自己年纪大了，不太适合长篇大论，小标题就不拟了，主要是简短闲谈。

rem是一个好东西。如果没有兼容IE8的顾虑，rem可以说是一个非常理想的单位。rem和em一样是相对单位，只是有别于em相对于父元素，rem相对于根元素html，即root em。这样的设定使得rem天生具备扁平级联的特性。早期IE不支持px单位的缩放，这是人们使用em单位的一个主要原因，但em单位存在过深的级联性，加大了组件的控制的难度，同时在某些嵌套标签非常多的时候，欠考虑的em也常常会出现意料之外的结果。正可谓成也级联败也级联。控制的好，很优雅，但恕我所见，这种优雅并不是很有必要，所以在大多数情况下，我总是推荐别人使用px。和年纪也有关系吧，毕竟刚毕业那会明明还那么热爱em～

当然如果不考虑IE8，直接使用rem是更好的选择。和em一样，将基础设置为10px是方便使用的第一步，比如html{font-size:62.5%}，这样所有页面元素可以用10的倍数来表示，1.5rem = 15px，以此类推，计算和使用都非常便捷——这看起来很美好，其实并没有什么用。比如Chrome的亚语言版本会强制字体大小12px以上，这个时候上面这个算式是无法达成的，你会发现即便html只是拿来做基础，如果不使出些旁门左道来，我们无法将其计算值设置为10px，当打开调试工具一看，12px搅黄了整个节奏。

那么基础设置成100px？这的确是可行的。只不过无端多出很多类似0.15rem这样的代码，嘿，还能剩掉个0写作.15rem提升一下逼格。不过，如果真这样用还是会遇到些小问题，我在早期浏览器刚刚支持rem的时候，总是能遇到浏览器在计算值的时候，闪烁出那硕大的100px字体。虽然在现代浏览器里我已经几乎没有遇到，但我已经习惯性地把基础设置为20px，虽然计算起来略有麻烦，但就个人使用应该没有问题。

字体说完了，接下来说边框。既然是标准单位，边框能用吗？当然没问题。但这里放开脑洞需要探寻一下边框是怎么处理rem的。假设现在的基础是10px，当设置边框0.1rem的时候，就是1px的红线，这点毫无疑问。那设置成0.01rem的时候呢？0.01rem自然是不够1px线宽的，所以不会有线。换个问题，如果是0.09rem呢？

计算上并没有什么疑问，0.09 * 10 = 0.9px，那么浏览器会认为0.9px是1px吗？

答案是否定的。这里我有些故弄玄虚了:)，其实这个问题跟rem半毛钱关系都没有。这和我们直接编写border:0.9px solid red;一样无用。好吧，绕回来，其实边框是不需要使用rem值的，上面是原因之一。更重要的是，边框并不需要级联的特性。所以边框用rem可以说是纯属强迫症行为～

所以说rem就是这么简单一个单位，简单到如果不谈它的定义它的行为，都写不出什么内容。但我还是想办法把文章拉长了！

未来，rem会显得稍微重要些，但也仅此而已了。很多年前，我们憧憬着一处样式在所有的设备上都能work，甚至是未来的超超超高风辨率屏幕，未来的虚拟现实技术，从而选择了看起来美好的东西，但事实往往会削弱这种愿景。当年IE无法缩放px，如今不在是问题。当年的流体布局混合进了当前响应式设计里，iPhone的出现让我们有了viewport，新的技术会为兼容旧的内容而努力，故而，选择了px贯彻始终的话，也决然，并不是一种罪过:)

总结：rem是基于根元素的相对扁平级联计算单位，典型适用于需要整体调整字体大小的场景，如多语言网站。

目前主流浏览器对CSS3 Media Queries的支持度已经非常好，那么就展望看看Media Query Level 4～前段时间抽空看了一下，就挑选几条感兴趣的说下。由于目前文档并非标准而只是工作草案，所以本文所列内容随时可能过期，只作为一个向导。

更新频度 update-frequency

查询设备的实际更新能力，取值也比较直观：

• none: 一旦渲染无法更新(比如打印机)
• slow: 更新缓慢(比如电子墨水)
• normal: 正常更新(比如我们更为熟悉的电脑屏幕)

这个查询可以为一些带有交互类的内容提供更多的外观控制，因为我们不是指定设备，而是根据设备的实际能力，对最终内容的样式加以优化。比如最简单的例子：

a{text-decoration:none;}
a:hover{text-decoration:underline;}
@media(update-frequency:none){
	a{text-decoration:underline;}
}

环境光 light-level

Level 4里添加了关于环境光的查询，这使得夜间模式变得可能。当然，现在已经有一些通过页面里的开关实现了类似开关灯的效果，效果其实也挺不错。甚至有一些浏览器单独实现了这样的一个模式，为夜间阅读注入特别的样式(主要是字体反白)。查询环境光需要光感传感器，由于现在手机上普遍已经搭载，所以light-level成为了一个很实际的功能。目前取值有三：dim(昏暗)，normal(普通)，washed(明亮环境，比如室外阳光下)。

这个查询看起来不错，不过实际操作起来是非常有难度的，因为很难界定。用户代理必须自己设定光亮的阀值，不同光感组件精度不同，而且手机自有的调亮功能也会影响到准确性，更不要说电子墨水在强光下的反而效果优秀了。所以，就目前而言这个特性显得比较空泛。

脚本能力 scripting

我们长期依赖noscript标签完成脚本支持的提示，但如果能查询到浏览器的脚本情况而应用不同的样式，岂非更好？所以 scripting 用来查询当前文档对脚本的支持情况。取值同样有三：

• enabled: 支持脚本并且已启用
• initial-only: 仅支持页面初始化脚本
• none: 不支持脚本，或虽然支持但未启用

initial-only 比较少见，但却是有用的，比如对于打印机而言，我们有必要得到仅仅是初始化完成的页面，但可能并不需要其他后续的交互结果。另外，“none”代表了不支持和不启用两者，是否有必要对两者加以区分？个人认为，没什么必要。区别对待的话，也许我们可以提供更准确的提示语句，然而在这个脚本横行的时代，有点显得多余。

指针 pointer

pointer代表了指点的精度，是我看到目前为止，LV4最有用的一个查询。

目前，我们使用媒体查询往往只是通过宽度判断我们的设备大小，我们总是在默认越小的设备诸如平板和手机，其指点精度都不高，故而需要放大交互原件的尺寸，尽管大体事实上确实如此，但我们显然需要更为直观的确定方式——直接查询指点的精度。

指点精度影响可以影响整个交互，所以显得额外重要，尤其是当标准试图将所有设备囊括其中时。pointer取值同时有三：none(无指点)，coarse(不精确，比如手指)，fine(精确，比如鼠标)，并且，缩放不影响值的判断。现在，我们就可以更为直观地加大我们的交互原件了：

@media (pointer:coarse) {
  input[type="checkbox"]{
    min-width:50px;
    min-height:50px;
  }
}

另一个重要的查询是 hover，即指点动作是否具有悬停能力。现代浏览器(特别是移动浏览器)对这个东西有各种特别处理，所以展开的话会超篇幅，放到下次单独写吧...

自定义查询 custom Media Queries

自定义查询，顾名思义，就是将定义好的某种查询命名，并可以在后续过程中组合使用。相对Level 3，Level 4添加了很多新的查询类型，这使得自定义查询变得有意义。只是即便如此，自定义查询的可用度还是太小了些。

结尾

还是学生时看Media Query还是遥不可及的梦，但几年一过，变化还真是很大。所以往前看一些总不会错的。虽然现在还用不上甚至显得鸡肋，但时间当真是转瞬，即逝。

BGM @ Don't Leave Me Now - Gregorian
BGM @ Believe ~instrumental~ - 梶浦由记

前段时间我同事对于margin和padding应用百分比值似乎有些误解，觉得可能是个普遍问题，所以觉得有必要拿出来单独写一下。

margin和padding都可以使用百分比值的，但有一点可能和通常的想法不同，就是 margin-top | margin-bottom | padding-top | padding-bottom 的百分比值参照的不是容器的高度，而是宽度。

引用标准(2.1)原来的表达：

The percentage is calculated with respect to the width of the generated box's containing block. Note that this is true for 'margin-top' and 'margin-bottom' as well. If the containing block's width depends on this element, then the resulting layout is undefined in CSS 2.1.

The percentage is calculated with respect to the width of the generated box's containing block, even for 'padding-top' and 'padding-bottom'. If the containing block's width depends on this element, then the resulting layout is undefined in CSS 2.1.

宽度参照宽度这点毫无疑问，但高度参照的也是宽度这点，可能就和通常的思路相左，因为毕竟height应用百分比参照的，依然是容器的高度。

关于为什么标准要这么定义，有几种通常的解释，就一并(个人)分析一下。由于padding和margin类似，下文就只以padding-top为例。

第一种说法是，padding-top如果以容器高度为参照，那么子元素应用padding值将会继续加高容器的高度，容器高度的变化又会反过来继续影响子元素的padding-top，陷入一个无限循环。

对于不定高的容器来说情况确实如此，但对定高容器则并不成立，这点和height类似，这也是为什么height的容器也必须确定好高度。也就是说，如果padding-top要参照容器高度，就必须和height一样做两种处理。

第二种说法则更为可靠，为了保持padding(margin)四个值的一统一。

padding(margin)的值无论引用何种计量，四个值都一直保持统一，难道单独给百分比开特例？结合第一条的多情况处理，如果标准定义padding-top参照容器高度的话，恐怕要列出至少4条以上的例外说明——而这对无论谁，都没有好处:)

事实上，垂直padding参照体是宽度这点也非常有用。虽然早期固化像素的设计中百分比值几乎不应用在padding或者margin上，但随着移动自适应的布局的需要，百分比也逐渐稀疏平常。比如配合background-sizing保持背景的比例，配合media query调整对应的间距，不一而足。这些应用都基于一个事实：无论垂直还是水平，百分比值始终参考宽度。

而宽度，实际上，正是自适应和现代web设计的灵魂。

前些日子，偶然发现zoom在iPhone6里没有起作用，而这之前，iOS7以下的Safari则确实支持zoom。可惜我并没有iPhone来测试这个问题，毕竟自己还在用着老诺的10年前的手机，手中也只有老婆淘汰下来的iTouch4，所以无法比较准确地做过多描述，只能粗糙地得到一个大概的结论。

虽然zoom的初衷是放大和缩小内容，但早期常用于触发IE内部haslayout属性，用做IE6-7的药方。作为一个早期IE的私有属性，其实现在的大部分浏览器也都能支持，故而也就有人使用其完成一些网页功能，比如移动端的网页内容的大小适配——相比对各个元素指定尺寸，一个zoom就能搞定绝对是懒惰开发者的福音。

说实在的，zoom在某些方面堪称实用，原因是CSS Transforms在内容占位上的效果可能非人所愿。用CSS Transforms替代zoom并非不可以，只是还需要关注缩放前后的位置大小，远没有zoom方便。而就是这么一个用法便利的尚未正名的属性，在最新的iPhone6面前不举了...按照iPhone的影响力，想来开发者不多久便会抛弃zoom。而对它的回忆，仿佛永远定格在

div{*zoom:1;}

更重要的结论是，要多赚钱，不然连个测试机都没有，目前双肾齐全，难道真要...

早些年闲的蛋疼的时候，写了一些关于CSS无关紧要的细节的的文章，如今因为繁忙恐怕难就再有这种功夫胡扯了。这些文章离现在最近的也快要超过1年半，是时候拿出来更新和回顾一下了。

• 2012/11/28 - 那些CSS的细节问题(1)
• 2013/01/06 - 那些CSS的细节问题(2) —— 圆角响应区
• 2013/02/15 - 那些CSS的细节问题(3) —— 圆角边框和overflow
• 2013/04/12 - 那些CSS的细节问题(4) —— 圆角边框和outline

由于这段时间以来，浏览器发展有些出乎意料(比如Opera改核)，所以我目前测试的范围已经缩小到只有IE9，Firefox32，Chrome38，本文结果也仅以这些版本为准。

细节(1) 里提到的内容有三点：

1. 鼠标指针样式的变化
2. 哪些CSS元素不占空间
3. 多重阴影的数量限制

第一点，浏览器是否会及时更新鼠标指针的样式。之前的结论是，Firefox是唯一即时更新鼠标指针样式的浏览器，不过时至今日，Chrome已经跟了上来，那我们把结论更新为：IE是唯一不即时更新鼠标指针样式的浏览器。

第二点，描述了哪些CSS元素不占空间。对于阴影不占据空间，虽标准早有定论，但早期版本Firefox实现错误，不过那也仅限于Firefox也嗑药飙版本号之前。如今，这部分内容不需要再特别说明。

第三点，我曾经蛋疼地试图寻找 box-shadow 的阴影数量限制，不过在测试数超过65535之后浏览器仍然正常渲染而放弃。得益于这些年各浏览器对于 box-shadow 的模糊算法的改进，也使得往日可能需要注意的一些细节变的更无关紧要。

细节(2) 讨论的是圆角后响应区的问题。当时，Chrome对圆角外空白部分仍然作出相应，而根据标准所述，曲线边界外的区域不接受指针事件，所以Firefox的实现比较正确。如今，Chrome已经更正了这个问题，表现同Firefox以及IE一致——仅圆角外的有内容的区域有响应。

细节(3) 测试的是各浏览器圆角 + overflow 的结果，由于这部分标准的模糊，浏览器表现也各异。但是当时的结论如今依然适用：所有的浏览器，在实现 border-radius 和 overflow:hidden; 共同作用的时候，都只是视觉上隐藏了文本，文本仍然有交互，即使那是曲面外的部分——理应没有任何的交互和响应。

细节(4) 讨论的是 outline 和 border-radius 的共同作用结果。如今再看测试用例，结果几乎没有变化，outline 与 border-radius 的矛盾似乎依旧将持续下去。并且，Firefox依旧没能描绘出最小轮廓(minimum outline)。

所谓温故而知新，尽管本来就是些无关紧要的东西。虽都是我写的文章，但回过头看仿佛真的不是出自自己之手。对于更早的长篇大论类的，就更觉陌生异常。除了一排汗，更多的还是对于变迁的感慨，和蛋蛋的忧伤——尼玛又少了好多能拿来装B的条目！还让人活吗？！

今天周五，各位，周末愉快。

时间追溯到4年前，那时刚出道，写了一篇CSS定位机制之一：普通流，转眼4年酱油人生，说好的浮动和绝对定位的篇幅也一拖4年。多少是因为对于熟悉的东西很难提起兴致，但更多还是因为懒惰。

这些年一过，浏览器环境的变化令人欣喜。当年甚少人讨论的BFC等概念，如今也已经说烂了。虽尚未满三十却深感锐气不比当年——说好的第二第三篇浮动和绝对定位应该不会有了，所以就随便聊聊浮动和绝对定位的一些麻烦之处——一些很多人可能不知道的，或者故意略过的，或者困惑的地方。

既然是浮动，那么首先第一个问题，什么是浮动？

如果是4年前的我，一定会摆出一堆定义，然后对着各种可能是人尽皆知的特性码很多字。如今，要是在让我解释什么是浮动，我只会说：“浮动===靠边”，并且我觉得我已经找不到比“靠边”更合适的词了。

假如我站在一个方阵队伍的中间，浮动的意思，无非就是靠边站，而且，应该不会有人在别人叫你靠边站的时候特意跑到另外一行队伍里去，这就是其中隐含的一个限制——“浮动发生在当前行”。

大部分时候我们不会思考浮动在RTL情况下会是怎样的，所以不失时机地想象一下RTL的浮动，可以锻炼大脑的抽搐功能，加深印象，效果大抵与错用左手类似。

带过了浮动是什么，下面就是正题了。

浮动外缘高度为零

相当一部分人并不知道，外缘高度为零的浮动不会缩短行框，因为这只是css2.1标准里的一段备注。但如果读过标准的内容，相信对这段话多少会催生出一些疑问：

A line box is next to a float when there exists a vertical position that satisfies all of these four conditions: (a) at or below the top of the line box, (b) at or above the bottom of the line box, (c) below the top margin edge of the float, and (d) above the bottom margin edge of the float.

Note: this means that floats with zero outer height or negative outer height do not shorten line boxes.

定义说，紧挨浮动的行框会缩短以提供浮动元素足够的空间。但所谓的“紧挨浮动的行框”需要同时满足垂直位置的4个条件。当浮动元素的外缘高度为零甚至为负时，行框无法满足上述定义的条件，也就不再受浮动的影响。所以标准这两段是因果关系，“this means”只是额外表明上述定义造成的一种特殊的结果。

当然，个人觉得，“当浮动元素没有外缘高度，不占据空间，也就不需要行框退让”这样的解释也是说的通的。而行框不缩短，在很大程度上使得浮动和绝对定位表现的很相似——内容溢出容器外会直接形成层叠。

同时浮动和绝对定位

这应该是一个愚蠢的问题：如果对一个元素同时使用浮动和绝对定位的话，会怎么样？

<div style="float:left;position:absolute;">葵中剑</div>

结果应该是显而易见的，元素绝对定位。但不能因为这个问题而产生困惑，因为两者可以共存。只是当元素绝对定位之后，浮动的值被计算为none。

这个问题可以被更复杂化，从而使得相当一部分人产生困惑：

<div style="display:none;float:left;position:absolute;">葵中剑</div>

也就是display:none;的情况下同时浮动和绝对定位，元素的各个值会如何？

我们知道，当元素display:none;之后，元素的position和float都不会被应用(具体可参见标准9.7节)。所以，这里需要分清的是计算值和是否被应用。这个例子里，position和float的计算值都不会受到影响(分别是absolute和left)，单单只是没有被应用而已。

现在去掉display:none;，position和float就被应用在元素上，此时，float的值又将被计算为none。

这个问题，问的是标准9.7节，隐含的则是计算值以及值是否被应用之间区别的理解。

CSS浮动最让人困惑的语句

标准里关于浮动部分，最让人困惑的语句莫过于9.5.1里的这段：

But in CSS 2.1, if, within the block formatting context, there is an in-flow negative vertical margin such that the float's position is above the position it would be at were all such negative margins set to zero, the position of the float is undefined.

如果你读过标准想必会对这句话有印象，这段话的上文是浮动行为的精确定义。我在第一次阅读的时候，这段话给我带来的困惑是最大的：“擦，啥玩意啊，undefined？”

造成困扰的原因有二：其一，作为非native speaker，即便自认为英语还不错，对于这种文法错乱加上混合了专有名词的句子，也有点力不从心。其二，这里的undefined并不是指值，而是指标准本身。

实际上，我之后看过很多人对这段内容的翻译，但实际上绝大部分都是硬着头皮来的，翻译出来的内容可能作者自己都未理解到位，词与句都甚为牵强。这个比较无奈，于是我只好把这段话发给一个懂css的老外，让他帮我断句，他是这样回复我的：

haha, terribly written sentence
quite confusing
So basically if you set the margins
the vertical margin
to something negative
-1 -2 etc
If the float position is above where it would be if the margins were at 0
then the position is considered "undefined"

这样就清楚多了，至少我一下子就明白了，这个该死的写出这段话的人究竟想说什么，而我再将其大概概括到最短：“垂直负边距的浮动位置在标准里没定义”。

没错，undefined指的是标准里没有相关的定义。为什么要加这么一段蛋疼的描述呢？9.5.1节那9条精确定义了浮动行为，其中，第5条第6条：

5. The outer top of a floating box may not be higher than the outer top of any block or floated box generated by an element earlier in the source document.

6. The outer top of an element's floating box may not be higher than the top of any line-box containing a box generated by an element earlier in the source document.

定义中没有例外。但例外恰恰是有的，那就垂直负边距。而所有的浏览器在实现时，浮动元素都会跟着垂直负边距移动，从而高于定义中的描述(具体参见CSS2.1 Issue 229)。为了修正标准，这句话应运而生了！不过糟糕的文法就实在不敢恭维...

好了，文章到这里也差不多了。欢迎吐槽我文中的错误和疏漏。最后祝大家国庆假期愉快～:)

一开始的起的标题是《Chrome中CSS3 transition和form导致的意外的onload动画》，不过太长了，所以最后删减了一下。但至少我遇到这个chrome的bug的时候，确实是transition和form同时出现时。

这个bug的具体的表现是：chrome会在页面加载后自动开始一段动画。

我使用的是chrome 36.0.1985.125 m，算是当前的最新版。页面中的全局样式添加了<a>的transition，而且还是非常偷懒的使用了all这样的参数，所以最后整个页面在加载完成后，所有的<a>都开始了过度效果，从尺寸到颜色，结果就导致了的整个页面的抖动。示例代码：

<!DOCTYPE HTML>
<html lang="en-US">
<head>
	<meta charset="UTF-8">
	<title></title>
    <link rel="stylesheet" href="style.css" />
</head>
<body>
<div class="wrapper">
	<a href="">Color Anime</a>
    <form action=""></form>
</div>
</body>
</html>

引用的样式文件内容也很简单：

a{color: #f30;
text-decoration:none;
-webkit-transition:all 1s;
-moz-transition:all 1s;
-o-transition:all 1s;
-ms-transition:all 0.3s;
transition:all 1s;}

经过一系列的尝试，发现这个bug只发生在齐备3个条件的情况下：

1. 使用了css3 transition。
2. 页面中有任意一个from，即便是空的。
3. 样式表文件为外链。

换言之，如果将样式直接写在页面里，是不会触发这个动画bug的。

之后就google了一下，看看是否有些其他信息。在chromium项目里看到了一些反馈，有好几个bug报告和这里描述的如出一辙，只是条件稍有不同。比如 Chrome CSS3 transition explode bug when form has three or more input elements，不仅给出了重现bug的例子，甚至还给出了hack方法：在<script>标签里至少有一个字符。

我试了试果然有效，诡异的处理方式啊，不过文中有一点没有提到，就是这个<script>标签必须出现在<form>之前。所以这个bug在实际工作中可能不常见，因为很少有页面满足这些条件。但是这确实是个非常让人讨厌的bug，一个纯CSS页面每次加载完都在面前动画一下，要是出现在某个内部系统里，当真要人命啊:)

可惜的是，虽然bug提出的很早，但至今都还未能修复。好几个相同的bug报告都已经被关闭，状态都是WONTFIX，可恶啊。这让我想起了几年前的Chrome Text-shadow的bug，一样好多人提，google一样慢如蜗牛的修，虽然最好还是修好了。好在google关掉的bug也有人继续提，所以，当前如果遇到这个bug，解决的方法，要么把样式写在页面里，要么就加上一个内容为空行的<script>标签，然后坐等google未来几年内可以搞定他。

上周有位网友simple_life(雷同学？)提了一个关于CSS的问题给我，因为当时非常忙所以没有时间回答。问题是这样的：

在css中，格式化上下文( Formatting context )和包含块( Containing block )是种什么关系？还有，浮动元素已经脱离了常规流，而块格式化上下文是描述常规流的，可是为什么又说块格式化上下文可以包含浮动元素？

总共是两个问题，简单说就是，FC和包含块是什么关系？以及，为什么BFC可以包含浮动元素？

一开始看到这两个问题时，其实我是非常迷惑的，有种不知道从何处开始回答的感觉，后来意识到可能是长期适应概念后对某些问题看的理所当然的缘故。所以现在虽然作答，但回答本身也不一定能让提出问题的人满意。

首先是，格式化上下文( Formatting context )和包含块( Containing block )是种什么关系？我其实想说，没什么关系。如果硬要说有什么关系的话，在FC中(无论是BFC还是IFC)，元素受制于包含块，元素的宽度、排布等都取决于包含块。举一个非常极端的例子，这个问题对我而言，等同于站在一个房间中，问“这个房间里的家具的摆放和这个房间有什么关系”？。两个概念，没什么直接关系，但是显然家具放在房间这样一个环境里，怎么放自然也和房间有关。

就如同标准的类似描述：“在块格式化上下文中，框从包含块的顶部开始依次垂直放置...在行格式化上下文中，行框的宽度取决于包含块以及浮动的存在...”——而这些都是在描述格式化上下文中，包含块所起到的作用。

第二个问题，浮动元素已经脱离了常规流，而块格式化上下文是描述常规流的，可是为什么又说块格式化上下文可以包含浮动元素？我的第一反应是，为什么BFC不能包含浮动元素，换言之，在我概念中似乎这是理所当然的事。另外对“块格式化上下文是描述常规流的”这样的描述也非常陌生，不知由来自哪里。

先举一个极端的例子来简短说明什么是常规流、浮动和定位：

• 现在一个班的学生要拍集体照，大家就按学号一个个走出来排成几排面对照相机。这就是最普通的流程。而如果中间任意一个同学要上厕所，那么那个空缺自然会被后面的同学填补上来。同学们依照既定的顺序(在代码中就是元素的顺序)依次排列。
• 然后摄影师觉得，某位同学站的位置有点靠后，让他上前一小步。这就是相对定位。
• 摄影师又觉得，某位同学太矮了，要让他直接靠边到队伍的最右边。这就是浮动。
• 最后，摄影师看了看镜头对老师说，你要站在这个位置。这就是绝对定位。

抛开诸多细节，CSS无非也就是做了这些事，排版引擎就如同摄影师一样依照每个学生自身高矮胖瘦的描述（没错，CSS就是描述）将他们排列出来。由于上下文(context)本来就是抽象词，这个例子里，照片在教室拍，那么环境就是教室。如果一个年纪拍集体照，那么环境就是操场，但又以每个班级为单位，班的概念就是新建的上下文环境，班中的队伍排列方式，和整个年级的排列完全无关。

回到刚才的问题，首先“脱离了常规流”这种抽象语句不是指浮动和常规流毫无关系，浮动恰恰与常规流密切相关。

然后，对于“块格式化上下文是描述常规流的”这样的语句，也算是一种抽象的理解者的造句，可能这就是最有疑问的地方。可能因为在CSS2标准里，块格式化上下文和行格式化上下文都是在常规流的章节中描述的，与常规流息息相关。但上下文这个概念原本的含义就类似于环境、语境，极端一些的例子：在这个世界里，会刮风，会下雨，会有地震，这些都是自然规律，描述了这个世界中规则(就像BFC和IFC描述了普通流的排布规则)，然而还是有人在这个世界上，一边迎合世界一边奉行自己的规则。

我们遵循标准所描述的规则，但标准本应该更为简单，却因为严谨而人为的抽象。其实想象一下，如果是自己在写标准，会怎么样？如果你是作者，你定义了常规流，表述常规流中的元素存在于一个叫BFC的东西里，如果先前没有定义过，那么下一步，你必然是要定义什么是BFC。所以BFC和IFC出现在常规流章节中并不奇怪，而且还是真正的文档的上下文的要求。

抱歉比较啰唆，可能也没能表达好，但我尽力了...最后祝你早日脱离标准苦海，毕竟这个坑挺深的...

能写文章，说明时间略有空余，这应该算好事吧～看了下草稿箱，果断还是选这篇先写完，因为和前面的几篇有关联。在之前的 圆角响应区 以及 圆角边框和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伪类与CSS伪元素的区别及由来》里，已经详细区分了伪类和伪元素。但在这篇讲应用的文章里，其实并不需要这么明晰的概念区分。本文也不会再重提单冒号和双冒号之间的区别，本文更关注如何更好的使用伪元素和伪类——通过罗列一些典型甚至是非典型的用法，讲述伪类和伪元素的一些使用上的小技巧。在这个过程中，始终忽略浏览器的支持情况，任何一个例子无法正确运行的话，请先检查一下你当前的浏览器，是否赶上了这个时代的浪潮～

当然，一开始都是一些比较常规的内容，如果你对这些内容已经了然，可以直接跳到后面“非典”的部分:)

列表处理

伪类与伪元素很大部分常规用途是在处理列表的。特别是 :nth-child() 这类结构伪类。

页脚链接

页脚链接可能是一个最为合适的例子，因为例子里伪元素和伪类并用。很多网站的页脚链接是用竖线分隔的罗列<a>标签形式。在这种页脚链接里使用伪类和伪元素的组合，就可以让链接的列表的HTML代码变得非常干净整洁：

ul.list{list-style:none;}
ul.list li{float:left;}
ul.list li:after{content:"\00a0|\00a0";}
ul.list li:last-child::after{content:"";}

但当前，放眼望去几乎不会有人这么做。绝大部分依然使用旧的方式。除了一些维护上的考量，习惯也是一个主要原因。熟优熟略这里不讨论，这里只是作为最典型的例子展示它们的应用。

最后项，奇偶项，倍数项

另一个广为人知的例子是：去掉列表最后一个元素的边框或者边距。在这种情况下，我们似乎已经习惯了给最后一个元素加上一个类似last-item的类名，然后单独写一条CSS规则。

ul.list li{margin-right:10px;}
ul.list li.last-item{margin-right:0;}

实际上，我自己在写的时候也会偏向一个早就习惯了的做法。在时间限定的情况下，不会考虑激进的方案，也不会考虑类似负边距或者超界显示等等优化方案，而只是一味的寻求最为保险和熟悉的习惯上的东西。习惯是可怕的顽固，所以可能今后还是会有很长一段时间不会写成下面这样：

#ul.list li{margin-right:10px;}
#ul.list li.last-child{margin-right:0;}

隔行背景色可能是奇偶项使用最多的情况，但现在又有多少人已经完全使用odd和even来替代额外添加的类名？

tr:nth-child(odd){background-color:#f4f4f4;}
tr:nth-child(even){background-color:#f9f9f9;}

还有诸如 Gallery 的特定项的边距，伪类的处理也不错不是嘛？

li:nth-child(3n) {margin-right:0;}

不过眼下，似乎更多人用负边距或者inline-block来处理，甚至直接让透明边距顶出容器，优化的手法已经很多，而且在维护性上甚至更有优势。

彩色

这其实还是上面的命题，但却单独拿出来说。如今的网页越来越多彩，也就不免单独指定一些亮丽的颜色。还是有很多人将特定的颜色用特定的类名标注。然而，如果颜色的映射顺序不怎么重要的话的，也许只是要达到多彩的简单目的，完全可以这么做：

li:nth-child(1) a{color:#f30;}
li:nth-child(2) a{color:#c0f;}
li:nth-child(3) a{color:#90f;}
li:nth-child(4) a{color:#06f;}
li:nth-child(5) a{color:#0cf;}

应对各种区块的色系调整，伪类的使用可以大幅减少HTML里的单一用途的类名。顺着这个例子推荐一个网站：xycss.com。这是一个由 Jeff Starr 建立的关于响应栅格布局的网站，他撰写的框架 xy.css 也有非常多的可以学习的地方。当然在这里举其作为例子还是因为这个网站的首页和这个例子相符——伪类实现的多彩的色块。

清除浮动

这是一个被讲烂的命题，不过我必须将其列在伪元素的典型应用的列表里，因为一般而言，伪元素(:after)在这里总是最为常见。之前我写的《再谈清除浮动》一文已经详细阐述过，所以这里不再冗述。唯一想顺带提一下的是，虽然清除浮动方法各异，但我自己其实挺偏向空标签的，原因嘛，还是习惯吧...

非典型应用

所谓的非典型应用其实无非就是“不干正经事”的意思，与当年的table多少有些神似。这部分里有一些已经淘汰的手法，但为了纪念它们存在的痕迹，还是将它们例举和提及。

阴影

如今的浏览器大部分都已经支持box-shadow这个方便的阴影制造器，也正因为此，box-shadow在如今的使用中颇为频繁。关于box-shadow的文章我也至少写过4篇：

• CSS3 box-shadow 详解(1)
• CSS3 box-shadow 详解(2)
• 再谈box-shadow
• 那些CSS的细节问题(1)中第三部分有关“多重阴影数量的限制”的讨论和测试

虽然如今愈发觉得这个属性存在被滥用的危险，但是实际使用时，制造阴影往往需要和伪元素一起使用，特别是当页面中的某些布局需要额外元素制造阴影的时候。由于凡是支持box-shadow的浏览器都支持伪元素，所以几乎任何时候要添加box-shadow，伪元素都是考虑范围之一。比如，给全局网页加上一个顶部的阴影渐变：

body:before{content:"";position:fixed;top:-15px;left:0;width:100%;height:15px;box-shadow:0px 0px 15px rgba(150,150,150,.8);}

你可以直接在我的网页顶部看到效果(2013年下半年改扁平化之后应该会移除)。

CSS调试

之前写的调试样式：debug.css，部分内容是有关 :empty 伪类的应用。

div:empty,
span:empty,
li:empty,
p:empty,
td:empty,
th:empty{padding:1em;background-color:#ff0 !important;}

:empty可以在开发过程中以可视化的方式过滤空标签。

额外的提示

比如给相应的链接增加相应的内容提示:

.example-block:before {
   content: "Example:";
}

在我的印象里，早期的W3c标准文档里就是类似这么干的。这种额外信息的提示源自伪元素和CSS Content的配合使用，更多例子推荐阅读 Chris Coyier写的 CSS Content

内描边和背景透明

这两个算是浏览器在CSS2的大时代背景里夹缝里生存的trick，如今看来早已经过时。现在的内描边可以用box-shadow轻而易举的完成，透明背景则需要用到CSS的RGBA以及IE滤镜。但当时，不知道是谁想出用四角绝对定位一个伪元素，然后画边框来实现内描边，应用opacity和IE透明滤镜来实现背景透明。虽然过时，但每每提起这种陈年旧事总是感觉好怀念啊～

最后

最后的最后，说起伪元素的应用，不得不提的是一个相当妖孽的网站：One Div，用一个DIV拯救世界吧，少年！查看代码就会发现，其中充斥了伪元素和box-shadow，这么多把阴影当画笔的图标，当真是，妖孽极了...

结语

这篇写了很久，思路断断续续的，写的不好，请见谅。水平有限写的不到位的，欢迎吐槽。

这期间浏览器翻天覆地的变化，让我觉得写些东西出来过不多久就要过时似的...Opera放弃内核，Chrome和Webkit分道扬镳，现在无法判断这些事是好是坏，总而言之，不学习一直停留着的话，真是要被洪流给吞了的...加了个油！

本篇是上篇《那些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