CSSASSCSSASSCSSASS

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

文章关键字 ‘haslayout’

关于ie8和它的ie developer tools

2009年08月23号,星期天

ie developers tools对于页面工作者来说,是个不错的调试html,css,js的有利工具,特别是ie8下的ie developers tools,已有媲美Firefox下的Firebug之势。
许多开发者担心升级ie8后,将无法使用ie7预览页面,其实根本不用担心这点,ie8下的ie developers tools可以选择浏览器模式来切换预览ie7的页面效果。

装上ie8后,按F12可以打开i developer tools(这个工具在ie8正式版下是附带的)。它的菜单栏的最后两项便是:浏览器模式和文本模式。
我们可以试一段代码:

你可以试着切换各种模式查看页面效果。
mode.jpg

IE developer tools可以说已经是今非昔比了。Firebug的很多好东西他学会了,而且还具备了很多firebug所没有的一些实用工具。下面我一一道来:

1. CSS的选择性修改和预览。以前的ie developer tools可以增加样式,但要修改原有样式,需要写新样式来覆盖。而且,样式不能选择性屏蔽。现在的这项功能虽然界面上很绌,但同firebug一样方便有效。
style.jpg

2 DOM结构修改。这个也是ie8下developer tools新招,尽管firebug早就有了。
除了HTML元素标签,都可以直接修改(相比firebug,ie8还可以直接修改class,id及其它html属性项),使用alt+E则可以进去修改全部(包括HTML元素标签——同Firebug)。
edit.jpg

3 DOM结构的查找。不过没有高级搜索,搜索范围是所有html标签,id、class名,textNode,即整个源文件。查找的的会高亮显示。
search.jpg
firebug上有个扩展插件叫Firefinder,查找起来应该更有针对性。

4.ie developer tools上还有三个额外的工具:一个是浏览器屏幕尺寸调整工具,一个是取色器,还一个是标尺工具。
tools.jpg

5.还有,ie developer tools的js调试功能也已经可以媲美firebug了。

关于ie8的一些事:
1. 装了ie8后,你原来的傲游,世界之窗等浏览器会使用什么内核?
我相信是ie8内核,但他们对于html+css的解释,应该是按ie7浏览器模式(或则更有可能是ie8兼容模式)来解释的。
傲游浏览器可以在max:config的高级选项中进行设置更改是否采用ie8标准渲染模式。

2. 关于针对ie8的hack
对区别ie6,ie7,ie8来说,前面的测试代码里已经可以看出,”_”和”*”在ie8下都不能识别,那剩下就是怎么区别ie8和FF了。其实,对于html+css的解释,ie和ff很少会出现差异。当然,留这么一手,还是有必要的。
“_”hack针对于ie6;”*”或”+”hack针对于ie6,ie7;”\9″hack则针对于ie6,ie7,ie8有效,剩下的没加hack的就是给FF的了。
测试如下:

3.用ie8浏览网页,在地址栏后头还可能跟着一个按钮——兼容性视图按钮(浏览本地页面文件似乎不会出现这个按钮)。点击这个按钮,网页就进入ie8浏览器兼容模式下的ie7文本模式。
compatible.jpg
如果网页中被加入了<meta http-equiv=”X-UA-Compatible” content=”IE=EmulateIE7″ />这句,说明网页已经采用ie8浏览器兼容模式下的ie7文本模式进行渲染了,就不会出现这个按钮。

4.ie8抛弃了haslayout私有属性?
前面说ie和ff很少会出现差异,我觉得很大原因因为是ie8抛弃了haslayout。
我们看一个由于haslayout引起的各浏览器的差异显示:

大家都知道,浮动元素应该是脱离文档流的,但是zoom:1会触发haslayout。所以在ie下,原本是应该脱离文档流的浮动元素仍然占据着文档空间,除非去除zoom:1;(注意对比FF和IE看看背景色的位置)。
然而我们会发现,ie8的效果一直同FF保持一致,并没有受haslayout影响。
可以再参考下这里ie私有属性haslayout的困扰

5.还发现ie8的一个小功能,是Firefox3.5所没有的。ie8可以忽视当前页签下的alert弹出框,在不关闭此弹出框的情况下就可以切换页签。
这个功能在遨游2.5和sougou浏览器也拥有。

斯芬克斯之谜续——IE下失效的margin-left/right

2009年05月26号,星期二

margin-left/right也会失效?
一般很多人遇到的margin失效都是纵向上面的:
一种情况是元素的确不支持margin-top/bottom(参看:关于margin-top/bottom在inline元素(non-Replaced)上不起作用的解释);
另一种情况则是元素产生了margin叠加(参看:如何避开麻烦的margin叠加(margin collapsing))。

那么margin-left/right怎么又会失效的呢?假如看过斯芬克斯之谜-IE私有属性haslayout的困扰那篇文章的童鞋,就会了解了:哦,又是haslayout啊。

我们来看看具体的失效代码:

我们会发现:.cont的margin:0 30px再IE下失效了。。。
好,既然说haslayout的问题,那么,我们知道,height属性会触发haslayout。去除.cont的height试试,果然margin-left/right起效了。
不过,不要急,我们可以消除触发子级元素的haslayout来解决失效,也可以给父级元素触发haslyout来解决这个问题:在.wrap上增加属性:zoom:1;
那么,所有谜团都在这里了吗?
我们试试,不改动其他属性,去除父级.wrap上的border。我们发现,margin-left/right也不会失效了…
(看来,border这个属性,还得多加研究啊。之前也遇到过类似border引起的问题的。。。)
haslayout的一点资料可以看这里:On having layout抄录

如何避开麻烦的margin叠加(margin collapsing)

2009年03月21号,星期六

斯芬克斯——ie私有属性haslayout这篇文章中,我们提到的第一个斯芬克斯之迷,其实就是一个margin叠加问题。
关于margin collapsing,在W3C中是有明文规范的,符合其规则的都将产生margin collapsing。W3C认为margin叠加后的布局界面更良好。

margin collapsing(css2.1规范)
margin collapsing(css2规范)

margin叠加现象(父子级别):

可以看出wrap未被子层的margin所撑开。

但是,这种margin叠加往往不是我们所想要的效果(一些人甚至将此称为一个bug:margin叠加bug,也有称高度不适应bug的)——平心而论,我们努力的要避开margin collapsing多少也有些违背了W3C的初衷。不过,由于ie下经常有意无意的会触发haslayout,从而会避开margin叠加,这使得浏览器间显示不一。因此,我们还是有理由在适当时候彻底避开margin叠加的。

那么,如何避免这种margin叠加现象呢?
(全文…)

斯芬克斯之迷——ie私有属性haslayout的困扰

2009年03月21号,星期六

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

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

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

那让我们来猜一下她的几个比较困惑的问题吧。
(全文…)

On having layout

2008年09月28号,星期天

上次我将遇到的ie bug发到blueidea上后。有人说是由于ul没触发layout产生的问题。虽然之前经常听到haslayout这个词,但一直没有看过。
网上找了一篇资料阅读了一下。果然明朗多了。
文章地址:http://bbs.blueidea.com/thread-2636904-1-1.html

抄录一些:

Internet Explorer 中有很多奇怪的渲染问题可以通过赋予其“layout”得到解决。John Gallant 和 Holly Bergevin 把这些问题归类为“尺寸bug(dimensional bugs)”,意思是这些 bug 可以通过赋予相应元素某个宽度或高度解决。

“Layout”是一个 IE/Win 的私有概念,它决定了一个元素如何显示以及约束其包含的内容、如何与其他元素交互和建立联系、如何响应和传递应用程序事件/用户事件等。
这种渲染特性可以通过某些 CSS 属性被不可逆转地触发。而有些 HTML 元素则默认就具有“layout”。

Layout 在显示盒子时有着不同寻常而且难以预料的效果,而且有时甚至会牵连到他们的孩子元素。
一个元素是否具有“layout”可能会引发如下的一些问题:
  IE 很多常见的浮动 bug 。
  元素本身对一些基本属性的异常处理问题。
  容器和其子孙之间的边距重叠(margin collapsing)问题。
  使用列表时遇到的诸多问题。
  背景图像的定位偏差问题。
  使用脚本时遇到的浏览器之间处理不一致的问题。

不同于标准属性,也不像某些浏览器的私有 CSS 属性,layout 无法通过某一个 CSS 声明直接设定 。也就是说没有“layout属性”这么一个东西,元素要么本身自动拥有 layout,要么借助一些 CSS 声明悄悄地获得 layout。
默认layout元素
下列元素应该是默认具有 layout 的:
<html>, <body> <table>, <tr>, <th>, <td> <img> <hr> <input>, <select>, <textarea>, <button> <iframe>, <embed>, <object>, <applet> <marquee>

下列 CSS 属性和取值将会让一个元素获得 layout:
position: absolute
绝对定位元素的包含区块(containing block)就会经常在这一方面出问题。
float: left|right
由于 layout 元素的特性,浮动模型会有很多怪异的表现。
display: inline-block
当一个内联级别的元素需要 layout 的时候往往就要用到它,这也可能也是这个 CSS 属性的唯一效果——让某个元素拥有 layout。“inline-block行为”在IE中是可以实现的,但是非常与众不同: IE/Win: inline-block and hasLayout 。
width: 除 “auto” 外的任意值
很多人遇到 layout 相关问题发生时,一般都会先尝试用这个来修复。
height: 除 “auto” 外的任意值
height: 1% 就在 Holly Hack 中用到。
zoom: 除 “normal” 外的任意值 (MSDN)
MS专有属性,无法通过校验。 不过 zoom: 1 可以临时用做调试。
writing-mode: tb-rl (MSDN)
MS专有属性,无法通过校验。

·在 IE7 中,overflow 也变成了一个 layout 触发器:

overflow: hidden|scroll|auto
这个属性在之前版本 IE 中没有触发 layout 的功能。
overflow-x|-y: hidden|scroll|auto
overflow-x 和 overflow-y 是 CSS3 盒模型中的属性,尚未得到浏览器的广泛支持。他们在之前版本IE中没有触发 layout 的功能。

·另外 IE7 的荧幕上又新添了几个 haslayout 的演员,如果只从 hasLayout 这个方面考虑,min/max 和 width/height 的表现类似,position 的 fixed 和 absolute 也是一模一样。

position: fixed
./.
min-width: 任意值
就算设为0也可以让该元素获得 layout。
max-width: 除 “none” 之外的任意值
./.
min-height: 任意值
即使设为0也可以让该元素的 haslayout=true
max-height: 除 “none” 之外的任意值
./.

以上结论借助 IE Developer Toobar 以及预先测试得出。