CSSASSCSSASS

三人行必有我师焉,择其善者而从之,其不善者而改之
三人行必有我师焉,择其善者而从之,其不善者而改之
三人行必有我师焉,择其善者而从之,其不善者而改之
三人行必有我师焉,择其善者而从之,其不善者而改之
三人行必有我师焉,择其善者而从之,其不善者而改之

  斯芬克斯之迷——ie私有属性haslayout的困扰 作者:ONEBOYS    发表时间: 2009年03月21号,星期六     阅读:3,613 次  

就象神话中的斯芬克斯一样,ie的私有属性haslayout是个神秘且让人困惑的难缠东西,她只游荡于ie(这片沙漠)之下。
她无法使用css声明直接创建。即便是对于ie,她也不能说是一个实实在在存在的属性。
ie下的元素有些本身拥有haslayout(基本上是一些拥有内在尺寸的可置换元素),有些可以通过一些css属性可以触发产生。

我们可以在ie developer toolbar上查看到到haslayout这个属性项,他的值是-1。这说明这个元素触发了layout。
详细haslayout资料:On having layout抄录
更详细资料:译文On having layout这篇文章本人还没怎么看,相信很多问题在这里都有解释

遇到斯芬克斯是件很麻烦的事情,她会给你提出很多怪怪的让人困惑的问题,更何况只要我们在ie沙漠中游荡的话,遇到的概率是非常高的。
遇到她,我们会有三种结果:
猜不出迷题的答案——我们会在迷失在困惑中;
猜错了迷题的答案——我们会误会很多东西;
猜对了迷题的答案——恭喜你,你就不用怕斯芬克斯这个丑婆娘了。

那让我们来猜一下她的几个比较困惑的问题吧。
阅读这个条目剩下部分 »

   

  关于margin-top/bottom在non-Replaced inline元素上不起作用的解释 作者:ONEBOYS    发表时间: 2009年02月27号,星期五     阅读:3,474 次  

margin-top/bottom have no effect on non-replaced inline elements。(参见css2.1规范)
但是为什么就不支持呢?
本人觉得可以这样解释:

像这样一个结构
<span class=”a”>xxxxxxxxxxxxxxxx</span><span class=”b”>——————</span>

效果大概如下
xxxxxxxxxxxxxxx————-

假如inline元素支持margin-top,而margin-top的参照基准是前一个元素(当然,考虑复杂情况的话,这么说是不正确的,比如前一元素是脱离文档流的元素,或者根本没有前一元素而只有上级元素,等等)。那么给b相对a的设置一个margin-top值,这个效果会是怎么呢?

这样?
xxxxxxxxxxxxxxx
————-

还是这样?
xxxxxxxxxxxxxxx
                                     ————-

但不管是怎样,这都和inline元素的定义相悖。inline元素,从字面上就可以理解,他是在(in)一行(line)上的!
这就是为什么inline元素当初设计的时候不让它支持margin-top/bottom。

同样他(非可置换inline元素)也不支持height(和width)。取而代之的是line-height,意思就是行高。因为inline元素是一行行的,定一个height的话,那这到底是整段inline元素的高呢?还是inline元素一行的高呢?都说不过去啊!所以统一都给每行定一个高,这就是line-height了。

虽然no-replaced inline元素都不支持margin属性。
但margin对于可置换inline元素还是有效的.(Replaced element )

例如下,下面的margin-top/bottom就生效了吧.

不过,等下,为什么在这里对inputButton设置margin-top后inputText也跟着有了上边距了呢?
其实,对于可置换inline元素的margin作用基线和block元素又不一样,他并非是任意的前面那个元素,而是离他最近的前一个block元素。
而且,对于元素有一个默认的vertical-align值。
ie下有可能是:vertical-align:auto; (但标准css规范中并无auto这个值)
而FF等浏览器下是vertical-align:baseline;(规范中所定义)

我们给input这个可置换inline元素设置个vertical-align:top;看看,前面的inputText是不是就看不出有“上边距”了。

有时候,margin的值在不同浏览器下会产生不同的结果。
比如这个:

对比下ie和FF的差别,我们会发现在,FF下这个margin负值似乎没起作用啊。
其实是vertical-align值(有默认值)在不同浏览器下解释有差别的缘故。
你可以修改input的vertical-align值做下测试。

   

  关于padding增加width的解释 作者:ONEBOYS    发表时间: 2009年02月27号,星期五     阅读:2,760 次  

在一个block元素上使用padding后元素实际的宽度会增加,这是一个常识。

这本来是一个很浅显的道理,但许多初学者考虑的时候却觉得很怪异。

我这里按自己的解释来说明一番。

给个假设情况:一个width:10px的元素,padding:10px;

那么实际宽度就是width+padding-left+padding-right=30px;

假如说padding对宽度无影响,那么width是10px;但是padding在横向的宽度是20px;这样内边距padding>总宽width。

一个元素的内边距却大于这个元素的总宽,显然这是个悖论。

所以说作为内边距的padding是一定要加在宽度之上的。