Magento 目录添加自定义属性例子

如何给magento的产品分类创建一个自定义属性?

在根目录创建个脚本文件,内容:

require_once('app/Mage.php');
Mage::app()->setCurrentStore(Mage::getModel('core/store')->load(Mage_Core_Model_App::ADMIN_STORE_ID));
$installer = new Mage_Sales_Model_Mysql4_Setup;
$attribute  = array(
    'type' => 'int',
    'label'=> 'Discount(%)',
    'input' => 'text',
    'global' => Mage_Catalog_Model_Resource_Eav_Attribute::SCOPE_GLOBAL,
    'visible' => true,
    'required' => false,
    'user_defined' => true,
    'default' => "",
    'group' => "General Information"
);
$installer->addAttribute('catalog_category', 'category_attribute_code
', $attribute);
//$installer->removeAttribute('catalog_category', 'category_attribute_hottest');
$installer->endSetup();

自定义属性的label和category_attribute_code自己更改。

脚本跑一遍,就在magento后台分类编辑页面的General Information组里新加了自定义属性。

IE 和Firefox的js兼容性总结

一、函数和方法差异

1
. getYear()方法

【分析说明】先看一下 以下代码:

var
year
=
new
Date().getYear();
document.write(year);

  在IE中得到的日期是"2010",在Firefox中看到的日期是"110",主要是因为在 Firefox 里面 getYear 返回的是 "当前年份-1900" 的值。

【兼容处理】

  加上对年份的判断,如:

var
year
=
new
Date().getYear();
year

=
(year
<
1900
?
(
1900
+
year):year);

document.write(year);

   也可以通过 getFullYear getUTCFullYear 去调用:

var
year
=
new
Date().getFullYear();
document.write(year);

 

2
. eval()函数

【分析说明】在IE中,可以使用eval("idName")或 getElementById("idName")来取得id为idName的 HTML对象;Firefox下只能使用getElementById("idName")来取得id为idName的HTML对象。

【兼 容处理】统一用getElementById("idName")来取得id为idName的HTML对象。

 

3
. const声明

【分析说明】在 IE 中不能使用 const 关键字。如:

const constVar
=
32
;

在IE中这是语法错误。

【兼 容处理】不使用 const ,以 var 代替。

 

4
. var

【分析说明】请看 以下代码:

echo
=
function
(str){
document.write(str);
}


pre>

  这个函数在IE上运行 正常,Firefox下却报错了。

【兼容处理】而在echo前加上var就正常了,这个就是我们提到var的目的。

 

5
. const 问题

【分析说明】在 IE 中不能使用 const 关键字。如 const constVar = 32; 在IE中这是语法错误。

【解决方法】不使用 const ,以 var 代替。

 


二、样式访问和设置

1
. CSS的"float"属性

【分析说明】Javascript访问一个给定CSS 值的最基本句法是:object.style.property,但部分CSS属性跟Javascript中的保留字命名相同, 如"float","for","class"等,不同浏览器写法不同。

在IE中这样写:

document.getElementById(
"
header
"
).style.styleFloat
=
"
left
"
;

在Firefox中这样写:

document.getElementById(
"
header
"
).style.cssFloat
=
"
left
"
;

【兼容处理】在写之前加一个判断,判断浏览器是否是IE:

if
(document.all){

   document.getElementById(
"
header
"
).style.styleFloat
=
"
left
"
;

}

else
{

  document.getElementById(
"
header
"
).style.cssFloat
=
"
left
"
;

}

 

2
. 访问<label>标签中的"for"

【分析说明】和"float"属性一样,同样需要使用不现的句法区分来访 问<label>标签中的"for"。

在IE中这样写:

var
myObject
=
document.getElementById(
"
myLabel
"
);

var
myAttribute
=
myObject.getAttribute(
"
htmlFor
"
);

在Firefox中这样写:

var
myObject
=
document.getElementById(
"
myLabel
"
);

var
myAttribute
=
myObject.getAttribute(
"
for
"
);

【兼容处理】解决的方法也是先 判断浏览器类型。

 

3
. 访问和设置class属性

【分析说明】同样由于class是Javascript保留字的原因,这两种浏览器使用不同的 JavaScript 方法来获取这个属性。

IE8.0之前的所有IE版本的写法:

var
myObject
=
document.getElementById(
"
header
"
);

var
myAttribute
=
myObject.getAttribute(
"
className
"
);

适用于IE8.0 以及 firefox的写法:

var
myObject
=
document.getElementById(
"
header
"
);

var
myAttribute
=
myObject.getAttribute(
"
class
"
);

  另外,在使用setAttribute()设置Class属性的时候,两种浏览器也存在同样的差异。

   setAttribute("className",value);

  这种写法适用于IE8.0之前的所有IE版本,注意:IE8.0 也不支持"className"属性了。

  setAttribute("class",value);适用于IE8.0 以及 firefox。

【兼容处理】

方法一,两种都写上:

var
myObject
=
document.getElementById(
"
header
"
);
myObject.setAttribute(

"
class
"
,
"
classValue
"
);
myObject.setAttribute(

"
className
"
,
"
classValue
"
);

 //
设置header的class为 classValue

方法二,IE和FF都支持 object.className,所以可以这样写:

var
myObject
=
document.getElementById(
"
header
"
);
myObject.className

=
"
classValue
"
;
//
设置header的class为classValue

方法三,先判断浏览器类型,再根据浏览 器类型采用对应的写法。

 

4
. 对象宽高赋值问题

【分析说明】FireFox中类似 obj.style.height = imgObj.height 的语句无效。

【兼容处理】统一使用 obj.style.height = imgObj.height + ‘px’;

 


三、 DOM方法及对象引用

1
. getElementById

【分析说明】先来看一组代 码:

<!--
input对象访问1
-->


<
input
id
="id"
type
="button"

value

="click me"
ōnclick
="alert(id.value)"/
>


  在 Firefox中,按钮没反应,在IE中,就可以,因为对于IE来说,一个HTML 元素的 ID 可以直接在脚本中当作变量名来使用,而Firefox中不可以。

【兼容处理】尽量采用W3C DOM 的写法,访问对象的时候,用 document.getElementById("id") 以ID来访问对 象,且一个ID在页面中必须是唯一的,同样在以标签名来访问对象的时候,用document.getElementsByTagName("div") [0] 。该方式得到较多浏览器的支持。

<!--
input对象访问2
-->


<
input
id
="id"
type
="button"
value
="click me"

 onclick
="alert(document.getElementById('id').value)" /
>

 

2
. 集合类对象访问

【分析说明】IE下,可以使用()或[]获取集合类对象;Firefox下,只能使用 []获取集合类对象。如:

document.write(document.forms(
"
formName
"
).src);

//该写法在IE下能访问到Form对象的scrc属性

 【兼容处理】将document.forms("formName")改为 document.forms["formName"]。统一使用[]获取集合类对象。

 

3
. frame的引用

【分析说明】IE可以通过id或者name访问这个frame对应的window对象,而Firefox只可以通过 name来访问这个frame对 应的window对象。

  例如如果上述frame标签写在最上层的window里面的htm里面,那 么可以这样访问:

IE: window.top.frameId或者window.top.frameName来访问这个window对象;

Firefox:只能 这样window.top.frameName来访问这个window对象。

【兼容处理】使用frame的name来访问frame对 象,另外,在IE和Firefox中都可以使用 window.document.getElementById(”frameId”)来访问这个frame对象。

 

4
. parentElement

【分析说明】IE中支持使用parentElement和parentNode获取父节点。而 Firefox只可以使用parentNode。 

【兼容处理】因为firefox与IE都支持DOM,因此统一使用 parentNode来访问父节点。

 

5
. table操作

【分析说明】IE下 table中无论是用innerHTML还是appendChild插入<tr>都没有效果,而其他浏览器却显示正 常。

【兼 容处理】解决的方法是,将<tr>加到table的<tbody>元素中,如下面所示:

var
row
=
document.createElement(
"
tr
"
);

var
cell
=
document.createElement(
"
td
"
);

var
cell_text
=
document.createTextNode(
"
插 入的内容
"
);
cell.appendChild(cell_text);
row.appendChild(cell);
document.getElementsByTagName(

"
tbody
"
)[
0
].appendChild(row);


 

6
. 移除节点removeNode()和removeChild()

【分析说明】appendNode在IE和Firefox下都能正常使用,但是removeNode只能在IE下用。

   removeNode方法的功能是删除一个节点,语法为node.removeNode(false)或者 node.removeNode(true),返回值是被删除的节点。

  removeNode(false)表示仅仅删除指定节点,然 后这个节点的原孩子节点提升为原双亲节点的孩子节点。

  removeNode(true)表示删除指定节点及其所有下属节点。被删除的 节点成为了孤立节点,不再具有有孩子节点和双亲节点。

【兼容处理】Firefox中节点没有removeNode方法,只能用 removeChild方法代替,先回到父节点,在从父节点上移除要移除的 节点。

node.parentNode.removeChild(node); 

 //
为了在ie和firefox下都能正常使用,取上一层的父结点,然后remove。

 

7
. childNodes获取的节点

【分析说明】childNodes的下标的含义在IE和Firefox 中不同,看一下下面的代码:

<
ul
id
="main"
>


<
li
>
1
</
li
>


<
li
>
2
</
li
>


<
li
>
3
</
li
>


</
ul
>


<
input
type
=button
value
="click me!"
onclick
=

"alert(document.getElementById('main').childNodes.length)"
>

分别用IE和 Firefox运行,IE的结果是3,而Firefox则是7。Firefox使用DOM规范,"#text"表示文本(实际是无意义 的空格和换行等)在Firefox里也会被解析成一个节点,在IE里只有有实际意义的文本才会解析成"#text"。

【兼容处理】

方法一,获取子节点时,可以通过node.getElementsByTagName()来回避这个问题。但是 getElementsByTagName对复杂的DOM结构遍历明显不如用childNodes,因为childNodes能更好的处理DOM的层次结 构。

方法二,在实际运用中,Firefox在遍历子节点时,不妨在for循环里加上:

if
(childNode.nodeName
=="
#text
"
)
continue
;
//
或者使用nodeType == 1。

这 样可以跳过一些文本节点。

延伸阅读

  《IE和FireFox中的childNodes 区别

 

8
. Firefox不能对innerText支持

【分析说明】 Firefox不支持innerText,它支持textContent来实现innerText,不过textContent没有像 innerText一样考虑元素的display方式,所以不完全与IE兼容。如果不用textContent,字符串里面不包含HTML代码也可以用 innerHTML代替。也可以用js写个方法实现,可参考《为firefox实现innerText属性
》一文。

【兼容处理】通过判断浏览器类型来兼容:

if
(document.all){
document.getElementById(

'
element
'
).innerText
=
"
my text
"
;
}

else
{
document.getElementById(

'
element
'
).textContent
=
"
my text
"
;
}

 


四、事件处理

  如果在使用 javascript的时候涉及到event处理,就需要知道event在不同的浏览器中的差异,主要的JavaScript的事件 模型有三种(参考《Supporting Three Event Models at Once
》),它们分别是NN4、IE4+和W3C/Safar。

 

1
. window.event

【分析说明】先看一段代码

function
et()
{
alert(event);

//
IE: [object]


}

  以上代码在IE运行的结果是 [object],而在Firefox无法运行。

  因为在IE中event作为window对象的一个属性可以直接使用,但是在 Firefox中却使用了W3C的模型,它是通过传参的方法来传播 事件的,也就是说你需要为你的函数提供一个事件响应的接口。

【兼容处 理】添加对event判断,根据浏览器的不同来得到正确的event:

function
et()
{
evt

=
evt
?
evt:(window.event
?
window.event:
null
); 

   //
兼容IE和Firefox


alert(evt);
}

 

2
. 键盘值的取得

【分 析说明】IE和Firefox获取键盘值的方法不同,可以理解,Firefox下的event.which与IE下的 event.keyCode相当。关于彼此不同,可参考《键盘事件中keyCode、which和charCode 的兼容性测试

【兼容处理】

function
myKeyPress(evt){

//兼容IE和Firefox获得keyBoardEvent对象

evt

=
(evt)
?
evt : ((window.event)
?
window.event :
""

  //
兼容IE和 Firefox获得keyBoardEvent对象的键值



var
key
=
evt.keyCode
?
evt.keyCode:evt.which; 

if
(evt.ctrlKey
&&
(key
==
13
||
key
==
10
)){ 

       //
同时按下了Ctrl和回车键


//
do something;


}
}


 

3
. 事件源的获取

【分析说明】在使用事件委托的时候,通过 事件源获取来判断事件到底来自哪个元素,但是,在IE下,event对象有srcElement属性,但是 没有target属性;Firefox下,even对象有target属性,但是没有srcElement属性。 

【兼容处理】

ele
=
function
(evt){
//
捕获当前事件作用的对象


evt
=
evt
||
window.event;

  return

    (obj=event.srcElement?event.srcElement:event.target;
);
}

 

4
. 事件监听

【分析说明】在事件监听处理方面,IE提供了attachEvent和detachEvent两个接口,而Firefox提供 的是 addEventListener和removeEventListener。

【兼容处理】最简单的兼容性处理就是封装这两套接 口:

function
addEvent(elem, eventName, handler) {
  

if
(elem.attachEvent) {
    elem.attachEvent(

"
on
"
+
eventName,
function
(){

                     handler.call(elem)});

     //此处
使用回调函数 call(),让this指 向elem



  }
else
if
(elem.addEventListener) {
    elem.addEventListener(eventName, handler,

false
);
  }

}

function
removeEvent(elem, eventName, handler) {
  

if
(elem.detachEvent) {
    elem.detachEvent(

"
on
"
+
eventName,
function
(){

                     handler.call(elem)});

     //此处
使用回 调函数call(),让this指向elem


  }
else
if
(elem.removeEventListener) {
     elem.removeEventListener(eventName, handler,

false
);
   }
}


  需要特别注意,Firefox下,事件处理函数中的this指向被监 听元素本身,而在IE下则不然,可使用回调函数call,让当前上下文指向 监听的元素。

 

5
. 鼠标位置

【分析说明】IE下,even对象有x,y属性,但是没有pageX,pageY属性;Firefox下,even对象有 pageX,pageY属 性,但是没有x,y属性。 

【兼容处理】使用mX(mX = event.x ? event.x : event.pageX;)来代替IE下的event.x或者Firefox下的event.pageX。复杂点还要考虑绝对位置。

function
getAbsPoint(e){

var
x
=
e.offsetLeft, y
=
e.offsetTop;

while
(e
=
e.offsetParent) {
x

+=
e.offsetLeft;
y

+=
e.offsetTop;
}
alert(

"
x:
"
+
x
+
"
,
"
+
"
y:
"
+
y);
}


 


五、 其他差异的兼容处理

1
. XMLHttpRequest

【分析说明】new ActiveXObject("Microsoft.XMLHTTP");只在IE中起作用,Firefox不支持,但支持XMLHttpRequest。

【兼容处理】

 

function
createXHR() {

var
xhr
=
null
;

if
(window.XMLHttpRequest){
xhr

=
new
ActiveXObject(
"
Msxml2.XMLHTTP
"
);
}

else
{

try
{
xhr

=
new
ActiveXObject(
"
Microsoft.XMLHTTP
"
);
}

catch
() {
xhr

=
null
;
}
}

if
(
!
xhr)
return
;

return
xhr;
}


 

2
. 模态和非模态窗口

【分析说明】IE中可以通过showModalDialog和showModelessDialog打开模态和非模态窗 口,但是Firefox不支 持。 

【解决办法】直接使用window.open(pageURL,name,parameters)方 式打开新窗口。 如果需要传递参数,可以使用 frame或者iframe。

 

3. 
input.type 属性问题

IE下 input.type属性为只读,但是Firefox下可以修改

 

4
. 对select元素的option操作

设置options,IE和Firefox写法不同:

Firefox:可直接设 置

option.text
=
'
foooooooo
'
;

IE:只能设置

option.innerHTML
=
'
fooooooo
'
;

删除一个select的option的方法:

Firefox:可以

select.options.remove(selectedIndex);

IE7:可以用

select.options[i]
=
null
;

IE6:需要写

select.options[i].outerHTML
=
null
;

 

5
. img对象alt和title的解析

【分析说明】img对象有alt 和title两个属性,区别在于,alt:当照片不存在或者load错误时的提示。

title:照片的tip说明, 在IE中如果没有定 义title,alt也可以作为img的tip使用,但是在Firefox中,两者完全按照标 准中的定义使用 

在定义img对象时。

【兼容处理】最好将alt和title对象都写全,保 证在各种浏览器中都能正常使用 。

 

6
. img的src刷新问题

【分析说明】先看 一下代码:

<
img
id
="pic"
onclick
= "this.src= 'a.jpg'"

 src
="aa.jpg"
style
="cursor: pointer"
/>

在IE 下,这段代码可以用来刷新图片,但在FireFox下不行。主要是缓存问题。

【兼容处理】在地址后面加个随机数就解决了: 

<
img
id
="pic"
onclick
= "javascript:this.src=this.src+'?'

     +Math.random()"src
="a.jpg"
style
="cursor: pointer"
/>

 

总结

  IE和Firefox的Javascript方面存在着不少的差异,要做到兼容,我觉得很有必要把 一些常见的整理成一个js库,如DOM的操 作,事件的处理,XMLHttpRequest请求等,或者也可以选择使用现有的一些库(如jQuery,YUI,ExtJs等),不过我觉得还是有必要 了解一下这些差异,这样对于我们参加兼容性和可用性代码很有帮助。

  办法总比问题多,无论浏览器兼容如何折腾人,做前端开发的总能迎 刃而解的!

a链接href="javascript:void(0);"或"javascript:;"在IE6下导致js跳转失败

 

经常有如下JS跳转写法:

 

<a href="javascript:void(0);" onclick="javascript:location.replace('http://www.baidu.com/');">test js location.replace()</a>

 

<a href="javascript:void(0);" onclick="javascript:location.href='http://www.baidu.com/';">test js location.replace()</a>

 

经测试,在IE6下上述两种JS跳转执行无响应,其它浏览器下均正常。

 

仔细分析,

 

猜测IE6下a链接的跳转会收到href属性中代码的影响,

 

上述代码的执行过程,貌似是先执行onclick事件中的代码,

 

而且是在onclick事件的回调函数返回true的情况下,

 

再执行href属性中的代码,

 

然后才作出跳转动作。

 

而正是void(0);代码阻止了浏览器跳转,

 

所以在onclick的代码最后,加上return false;让onclick回调函数返回false值,

 

以阻止执行href属性中的代码,

 

这样就可以让浏览器顺利跳转。

[译文]On having layout

译者注:一篇很好的文章,很久以前在blog上就推荐过,这两天断断续续花了点时间翻译了一下,推荐读读。
英文原文在此。
http://www.satzansatz.de/cssd/onhavinglayout.htm
文中所有的 layout 这个单词都未作翻译,一来本身这个单词意思就比较多,翻成啥都觉得别扭,二来它也是专有的属性,所以就意会一下吧。水平有限,很多地方都是模模糊糊地意译,发现错误欢迎留言指出。
引用一段来自Dean Edwards
的评价:
I recommend that every CSS designer and DOM scripter read this. Understanding “layout” gives a huge insight into lots of other IE bugs and idiosyncrasies.
(Dean Edwards)

4月16日修订的内容
将quirks模式这一部分单独移动到一篇文章中讲述。
添加:边缘裁切。
添加:收缩包围(shrink-wrapping)现象。

5月17日修订的内容
重写了了浮动元素旁边的元素这一部分。
部分章节小的修正:属性,有关内联级别元素,CSS hacks。
重新整理了部分章节的语言:定义,数据,问题种种,分析,清除浮动和自动扩展适应高度,绝对定位元素。


On having layout

本文修订中
当前版本:Rev. 7 2006–05–17
http://www.satzansatz.de/cssd/onhavinglayoutrev07-20060517.html
修订历史
http://www.satzansatz.de/cssd/layoutchangelog.html
各种语言版本
目录


介绍


Internet Explorer 中有很多奇怪的渲染问题可以通过赋予其“layout”得到解决。John Gallant 和 Holly Bergevin 把这些问题归类为“尺寸bug(dimensional bugs)”,意思是这些 bug 可以通过赋予相应元素某个宽度或高度解决。这便引出关于“layout”的一个问题:为什么它会改变元素的渲染特性,为什么它会影响到元素之间的关系?这 个问题问得很好,但却很难回答。在这篇文章中,我们专注于这个复杂问题会有那些方面的表现,某一方面的具体讨论和范例请参考文中给出的相关链接。



hasLayout — 定义



“Layout”是一个 IE/Win 的私有概念,它决定了一个元素如何显示以及约束其包含的内容、如何与其他元素交互和建立联系、如何响应和传递应用程序事件/用户事件等。
这种渲染特性可以通过某些 CSS 属性被不可逆转地触发。而有些 HTML 元素则默认就具有“layout”。
微软的开发者们认为元素都应该可以拥有一个“属性(property)”(这是面向对象编程中的一个概念),于是他们便使用了 hasLayout,这种渲染特性生效时也就是将 hasLayout 设成了 true 之时。
术语
当我们说一个元素“得到 layout”,或者说一个元素“拥有 layout” 的时候,我们的意思是指它的微软专有属性 hasLayout http://msdn.microsoft.com/worksh ... rties/haslayout.asp 为此被设为了 true 。一个“layout元素”可以是一个默认就拥有 layout 的元素或者是一个通过设置某些 CSS 属性得到 layout 的元素。
而“无layout元素”,是指 hasLayout 未被触发的元素,比如一个未设定宽高尺寸的干净 div 元素就可以做为一个“无layout祖先”。
给一个默认没有 layout 的元素赋予 layout 的方法包括设置可触发 hasLayout = true 的 CSS 属性。参考默认 layout 元素以及这些属性列表。没有办法设置 hasLayout = false , 除非把一开始那些触发 hasLayout = true 的 CSS 属性去除。



问题种种


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

上面的列表只是列出一个大概,也不完善。下面的文章将尽可能详细彻底的描述有无“layout”所带来的各种问题。



Layout 从何而来


不同于标准属性,也不像某些浏览器的私有 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

http://www.brunildo.org/test/InlineBlockLayout.html

 

width: 除 “auto” 外的任意值

 

很多人遇到 layout 相关问题发生时,一般都会先尝试用这个来修复。

 

height: 除 “auto” 外的任意值

 

height: 1% 就在 Holly Hack 中用到。

 

zoom: 除 “normal” 外的任意值 (MSDN)

http://msdn.microsoft.com/worksh ... properties/zoom.asp

MS专有属性,无法通过校验。 不过 zoom: 1 可以临时用做调试。

 

writing-mode: tb-rl (MSDN)

http://msdn.microsoft.com/worksh ... ies/writingmode.asp

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 以及预先测试得出。


有关内联级别元素

对于内联元素(可以是默认即为内联的比如 span 元素,也可以是 display: inline 的元素)

 

width 和 height 只在 IE5.x 下和 IE6 或更新版本的 quirks 模式下触发 hasLayout 。而对于 IE6,如果浏览器运行于标准兼容模式下,内联元素会忽略 width 或 height 属性,所以设置 width 或 height 不能在此种情况下令该元素具有 layout。

 

zoom 总是可以触发 hasLayout,但是在 IE5.0 中不支持。


 

具有“layout” 的元素如果同时也 display: inline ,那么它的行为就和标准中所说的 inline-block 很类似了:在段落中和普通文字一样在水平方向和连续排列,受 vertical-align 影响,并且大小可以根据内容自适应调整。这也可以解释为什么单单在 IE/Win 中内联元素可以包含块级元素而少出问题,因为在别的浏览器中 display: inline 就是内联,不像 IE/Win 一旦内联元素拥有 layout 还会变成 inline-block。


脚本属性 hasLayout

我们这里称 hasLayout 为“脚本属性”是为了和我们熟知的 CSS 属性相区别。

 

注意一旦一个元素拥有了 layout,就没有办法再将其设成 hasLayout = False 了。

 

hasLayout-property

http://msdn.microsoft.com/worksh ... rties/haslayout.asp

可以用来检测一个元素是否拥有 layout:举个例子,如果它的 id 是“eid”,那么只要在 IE5.5+ 的地址栏里输入 javascript: alert(eid.currentStyle.hasLayout) 即可检测它的状态。

 

IE的 Developer Toolbar

http://www.microsoft.com/downloa ... &displaylang=en

可以实时检查一个元素的当前样式;如果 hasLayout 是 true ,那么它的值显示为 “-1”。 我们可以通过实时修改一个元素的属性将“zoom(css)”设置为“1”来触发 hasLayout 以便调试。

 

另外一个需要注意的是“layout”会影响脚本编程。如果一个元素没有“layout”,那么clientWidth/clientHeight 总是返回0。这会让一些脚本新手感到困惑,而且这和 Mozilla 浏览器的处理方式也不一样。不过我们可以利用这一点在 IE5.0 中检测“layout”:如果 clientWidth 是零那么这个元素就没有 layout。





CSS hacks


 

下面用于触发 haslayout 的 hack 已经经过 IE6 及以下版本测试。今后版本的IE有可能会对此做不同处理。如果新版本浏览器发布我们会重新整理这部分内容。

 

John Gallant 和 Holly Bergevin 在2003年发布的 Holly hack

http://www.communitymx.com/conte ... age=2&cid=C37E0

复制内容到剪贴板
代码:

/* \*/  * html .gainlayout { height: 1%; }  /* */

可以让 IE5+ 的任意元素获得 layout,除了标准兼容模式 IE6 中的内联元素。

 

一般都很有效,除了在某些极少情况下,需要用 height:0 或者 1px 更好一些。

 

和 overflow: hidden 不相容,除非在 IE6 的标注兼容模式下(因为这时如果父元素没有定高,那么height: 1% 会被变回 height: auto)。


 

或者我们可以用 underscore hack:http://wellstyled.com/singlelang.php?lang=en&page=css-underscore-hack.html

复制内容到剪贴板
代码:

.gainlayout { _height: 0; }

另外,更具有向后兼容性的方法是使用 条件注释(conditional comments):http://msdn.microsoft.com/workshop/author/dhtml/overview/ccomment_ovw.asp

复制内容到剪贴板
代码:

<!--[if lte IE 6]>
<style>
.gainlayout { height: 1px; }
</style>
<![endif]-->  

在条件注释中链接一个专门对 IE/Win 做修正的外部样式表文件,也不失为一个安全有效的好方法:

复制内容到剪贴板
代码:

<link rel="stylesheet" href="allbrowsers.css" type="text/css" />
    
<!--[if lte IE 6]>
<link rel="stylesheet" href="iefix.css" type="text/css" />
<![endif]-->

我们更倾向于使用 height: 0 和 1px —— 并主张始终使用 height 除非它和别的什么东西冲突 (overflow: hidden)。对于取值,我们则倾向于避免 1% ,因为它可能会(虽然很少)引起一些问题。

http://www.brunildo.org/test/relayout.html

height 不能应用于标准模式下的内联元素。在这种情况下我们可以用 display: inline-block 或 zoom: 1。

 

我们曾看过一些把 Holly hack 真的当作 holy(神圣的) hack 盲目使用的情况,比如对浮动元素使用或者对已经具有特定宽度的元素也使用这个 hack。要记住这个 hack 的目的不是要给某个元素加一个高度,而只是要触发 hasLayout = True 而已。

 

不要给所有元素设置 layout:* {_height: 1px;}。所谓过犹不及,获得 layout 不等于获得灵丹妙药,它只是用来改变渲染模式。


Hack整理

但是浏览器总是会变的,我们需要面对很多问题,比如一些依赖 IE6 的 bug 所做的 hack 会在 IE7 或更高版本的新浏览器中因 bug 修复而失效(甚至有害)的问题;比如新版本浏览器中类似的布局 bug 依然存在但用于 hack 的过滤器比如 * html 却不能正常工作的问题。这种情况下,MS专有属性 zoom 就可以考虑使用了。

复制内容到剪贴板
代码:

<!--[if lt IE 7]><style>
/* IE 6 + IE5.5 + IE5.0 所用样式*/
.gainlayout { height: 0; }
</style><![endif]-->
    
<!--[if IE 7]><style>
.gainlayout { zoom: 1;}
/* 或者其他任何以后可能需要的东西 */
</style><![endif]-->

zoom: 1; 可以让 IE5.5+ 的任何元素(包括内联元素)获得 layout,但是在 IE5.0 中无效。

 

没有其他附带效果(内联元素会变成 inline-block,这个当然)。

 

如果需要通过验证,应该用条件注释将 zoom 隐藏起来。


 

其实当我们考虑到“向后兼容”时是很自相矛盾的,我们强烈建议页面设计者回过头看一下自己页面中用的到的明显的或是不明显的“hacks”,并用条件注释针对不同浏览器重新处理以保万无一失。





关于IE Mac 的小问题

 

IE Mac 和 windows 下的 IE 是完全不同的两个东西,它们各自拥有自己的渲染引擎,IE Mac 就全然不知“hasLayout”(或contenteditable)所谓何物。相比之下 IE Mac 的渲染引擎要更标准兼容一点,比如 height 就是被当作 height 处理,没有别的效果。因此针对“hasLayout”的 hacks 和别的解决方法(特别是通过使用 height 或 width 属性的)往往对 IE Mac 来说是有害的,所以需要对其隐藏。更多的关于 IE Mac 相关的问题可以在 IE Mac, bugs and oddities pages

http://www.l-c-n.com/IE5tests/

找到。




MSDN 文档

 

MSDN 中涉及到 hasLayout 这个 MS 属性的地方寥寥无几,而具体解释 layout 和 IE 渲染模型之间关系的则少之又少。

 

在IE4的时候,除了未经绝对定位也未指定宽高的内联元素,几乎所有元素都有某种 layout(MSDN)。

http://msdn.microsoft.com/worksh ... mentandlocation.asp

在这种早期的layout概念中,像 border, margin, padding 这些属性被称作“layout属性”,它们是不能应用到一个简单的内联元素上的。换句话说,“拥有layout”就可以粗略理解成:“可以拥有这几个属性”。

 

MSDN 上仍然使用 layout 属性这种说法, 只是含义变了,它们和拥有 layout 的元素已经没有什么关系了。在 IE5.5 中方才引入了 MS 的这个专有属性 hasLayout,

http://msdn.microsoft.com/worksh ... rties/haslayout.asp

也只是某种内部的标志位而已。

 

在 IE5.5 中,MSHTML Editing Platform(即可以通过设置来允许用户实时编辑、拖动 layout 元素以及调整其尺寸等)的文档中描述了三个和 layout 相关的重要特性:

 

如果一个 layout 元素中有内容,内容的排版布局将由它的边界矩形框决定。

 

拥有 layout 的意思基本上就是表示某元素是一个矩形。

 

从内部来说,拥有 layout 意思就是一个元素将自己负责绘制其内部内容。


 

(Editing Platform)

http://msdn.microsoft.com/librar ... mshtmleditplatf.asp
 

和 layout 自身相关的内部工作机制直到2005年8月才有相应文档描述,当时由于 The Web Standards Project

http://www.webstandards.org/

和微软的特别工作小组的原因,Markus Mielke [MSFT] 打开了深入讨论的大门:

 

一般来说,在 Internet Explorer 的 DHTML 引擎中,元素是不对自己的位置安排负责的。虽然一个 div 或者一个 p 元素都在源码中有一个位置,在文档流有一个位置,但是它们的内容却是由它们最近的一个 layout 祖先(经常是 body)控制安排的。这些元素依赖它们祖先的 layout 来为他们处理诸如决定大小尺寸和测量信息等诸多繁重的工作。


 

(HasLayout概述)http://msdn.microsoft.com/library/default.asp?url=/library/en-us/IETechCol/cols/dnexpie/expie20050831.asp




分析


 

我们的分析试图解释在已知案例下发生了什么事情,这种分析也应该可以作为未知案例下的指导。但我们这种试图利用种种测试案例投石探路的黑箱测试方法,是注 定无法消除黑箱的神秘感的——我们无法回答“为什么”的问题。我们只能去尝试了解整个“hasLayout”模式的工作框架,以及它会怎样影响网页文档的 渲染。因此,最终我们只能提供一些指导方针(而且只能是指导方针,而不是绝对的解决方案)。

 

我们认为他们所指的是一个小窗体。一个 layout 元素的内部内容是完全独立的,而且也无法影响其边界外的任何内容。

 

而 MS 属性 layout 只是某种标志位:一旦它被设定,这个元素就会拥有 layout“特性”,这包括体现在其自身以及其非 layout 孩子元素身上的特殊性能——比如浮动和层叠等。

 

这种独立性也许正可以解释为什么 layout 元素通常比较稳定,而且它们可以让某些 bug 消失。这种情况的代价有二,一是偏离了标准,二是它没有考虑到今后可能因此出现的 bug 和问题。

 

MS 的“页面”模式,从符号学角度考虑,可以看做是由很多互不相关的小的区块构成,而 HTML 和 W3C 的模式则认为“页面”模式应该是叙述完备的,故事性的相关信息区块构成的。





各种情况的详细说明



清除浮动和自动扩展适应高度

浮动元素会被 layou 元素自动包含。这是很多新手经常遇到的问题:在 IE 下完成的页面到了标准兼容浏览器下所有未清除的浮动元素都伸出了其包含容器之外。

 

Containing Floats

http://www.complexspiral.com/publications/containing-floats

how to clear floats without structural markup

http://positioniseverything.net/easyclearing.html
 

相反的情况:如果确实需要一个浮动元素伸出其包含容器,也就是自动包含不是想要的效果时,该怎么办?你很可能也会遇到这种头疼的问题,下面的深入讨论就是一个例子:

 

acidic float tests

http://www.satzansatz.de/cssd/acidicfloat.html
 

在IE中,一个浮动元素总是“隶属于”它的 layout 包含容器。而后面的元素会受这个 layout 包含容器影响而不是这个浮动元素影响。

 

这个特性和IE6的那个自动扩展以适应内部内容宽度的特性,都可以看成是受这个规则影响的:“由它的边界矩形框决定”。

 

更糟的问题:clear 无法影响其 layout 包含容器之外的 float 元素。如果依赖这个 bug 在 IE 中布局的页面要转到标准兼容浏览器中,只有全部重做。

 

IE 的自动包含浮动元素也是经常需要的效果,它在其他浏览器中也可以达到:参考我们的 “和 CSS 规范类似的地方” 这一部分来了解一下包含浮动元素的相关内容。


浮动元素旁边的元素

当一个块级元素紧跟在一个左浮动元素之后时,它应该——作为一个块级元素——忽略这个浮动元素,而它的内容则应该因这个浮动元素而移位:一个紧跟在左浮动 元素后的块级元素内的文字内容,应该沿着浮动元素的右边顺序排列并会(如果它的长度超过浮动元素)继续排列到浮动元素下方。但是如果这个块级元素有 layout,比如由于某种原因被设置了宽度,那么这整个元素则会因浮动元素而移位,就好像它自己也是一个浮动元素一样,因此其中的文字就不再环绕这个左 浮动元素了(而会形成一个矩形区域,保持在它的右边。)

 

在 IE5 中一个块级元素的百分比宽度是基于浮动元素旁边的剩余空间计算的,而在 IE6 中则是依照整个父块级元素的可用空间计算的。所以在 IE6 中设置 width: 100% 会导致某种浮动元素旁边的溢出现象,于是各种布局问题也会因此而来。

 

一些关于浮动块旁边的 hasLayout 块的测试案例:

 

by using width

http://dev.l-c-n.com/IEW2-bugs/float-layout.php

by using min-width (IE 7) and zoom (IE 6)

http://dev.l-c-n.com/IEW2-bugs/float-adjecant.php
 

与此类似,和浮动元素相邻的相对定位元素,它的位置偏移量应该参照的是父元素的补白(padding)边缘(例如,left: 0; 应该将一个相对定位元素叠放于它前面的浮动元素之上)。在 IE6 中,偏移量 left: value; 是从浮动元素的右边距(margin)边缘开始算起的,这会因浮动元素所占的宽度变化导致水平方向的错位(一个解决方法是用 margin-left 代替,但是也要注意如使用百分值时会有一些怪异问题)。

 

layout blocks with relative positioning adjacent to floated blocks

http://dev.l-c-n.com/IEW2-bugs/float-layout2-rp.php
 

根据规范所述,浮动元素应该与其后的盒子交织在一起。而对于没有交叉的二维空间中的矩形而言这是无法实现的。

 

如果谁真的需要向 IE 的这种不当行为屈服,那么如何让标准兼容浏览器中的盒子也有类似行为——即类似于 layout 盒子会自动“收缩”而给其前置的浮动元素让出空间的行为——就是一个问题了。我们给出的方法是跟着一个浮动元素创建一个新的块级格式化范围(block formatting context),这在我们的“和 CSS 规范类似的地方” 有讨论。

 

可以(再次)访问下面这个页面:

 

three pixel text-jog

http://positioniseverything.net/explorer/threepxtest.html
 

我们可以看到跟在一个浮动元素后的 layout 元素不会显示这个3px间隙的 bug,因为浮动元素外围的3px硬边无法影响一个 layout 元素的内部内容,所以这个硬边将整个 layout 元素右推了3px。好比一个防护罩,layout 可以保护其内部内容不受影响,但是浮动元素的力量却将整个防护罩推了开来。


列表

无论是列表本身(ol, ul) 还是单个的列表元素(li),拥有 layout 后都会影响列表的表现。不同版本 IE 的表现又有不同。最明显的效果就体现在列表符号上(如果你的列表自定义了列表符号则不会受这个问题影响)。这些符号很可能是通过某种内部机制附到列表元素 上的(通常是附着在它们外面)。不幸的是,由于是通过“内部机制”添加的,我们无法访问它们也无法修正它们的错误表现。

 

最明显的效果有:

 

列表获得 layout 后,列表符号会消失或者被放置在不同的或者错误的位置。


 

有时它们又可以通过改变列表元素的边距而重新出现。这看起来似乎是以下事实导致的结果:layout 元素会试图裁掉超出其边界的内部内容。

 

列表元素获得 layout 之后,会有和上面一样的问题出现,更多参考 (extra vertical space between list items)http://www.brunildo.org/test/IEWlispace.php


 

进一步又有一个问题就是(在有序列表中)任何具有 layout 的列表元素似乎都有自己独立的计数器。比如我们有一个含五个列表元素的有序列表,只有第三个列表元素有 layout。我们会看到这样:

 

1… 2… 1… 4… 5…

 

此外,如果一个有 layout 的列表元素跨行显示时,列表符号会底部对齐(而不是按照预料的顶部对齐)。

 

以上某些问题还是无法解决的,所以如果需要列表符号的时候最好避免让列表和列表元素获得 layout。如果需要限定尺寸,最好给别的元素设定尺寸,比如给整个列表外面套一个元素并设定它的宽度,又或者比如给每个列表元素中的内容设定高度等等。

 

另一个IE中列表的常见问题出现在当某个 li 中的内容是一个 display: block 的锚点(anchor)时。在这种情况下,列表元素之间的空格将不会被忽略而且通常会显示成额外的一行夹在每个 li 之间。一种避免这种竖直方向多余空白的解决方法是赋予这些锚点 layout。这样还有一个好处就是可以让整个锚点的矩形区域都可以响应鼠标点击。


表格

table 总是有 layout 的,它总表现为一个已定义宽度的对象。在IE6中,table-layout: fixed

http://msdn.microsoft.com/worksh ... ies/tablelayout.asp

通常和一个宽度设为100%的表格相同,同时这也会带来很多问题(一些计算方面的错误)。另外在IE5.5和IE6的quirks模式下还有一些别的需要注意的情况。

http://dev.l-c-n.com/tables_2/
相对定位元素(r.p.)

注意,由于 position: relative 并不触发 hasLayout,所以很多诸如内容消失或错位的渲染错误就会因此而起。这些现象可能会在刷新页面、调整窗口大小、滚动页面、选中内容等情况下出现。原 因是 IE 在据这个属性对元素做偏移处理时,却似乎忘了发出信号让其 layout 孩子元素进行“重绘”(而如果是一个layout元素,那么在其重绘事件的信号链中,这个传给其孩子的信号是会正常发出的)。

 

r.p. parent and disappearing floated child

http://www.satzansatz.de/cssd/rpfloat.html

disappearing list-background bug

http://positioniseverything.net/explorer/ie-listbug.html
 

以上是一些相关问题的描述。作为经验之谈,相对定位一个元素时最好给予其 layout。再有,我们也需要检查拥有这种结构的父元素是否也需要 layout 或者position: relative亦或二者都需要,如果涉及到浮动元素这点就十分重要。


绝对定位元素(a.p.):
包含区块,什么是包含区块?

理解 CSS 的包含区块概念很重要,它回答了绝对定位元素是相对哪里定位的问题:包含区块决定了偏移起点,包含区块定义了百分比长度的计算参考。

 

对于绝对定位元素,包含区块是由其最近的定位祖先决定的。如果其祖先都没有被定位,那么就使用初始包含区块 html。

 

通常情况下我们会用 position: relative 来设定任意包含区块。这就是说,我们可以让一个绝对定位元素所参考的原点和长度等不依赖于元素的排列顺序,这可以满足诸如“内容优先”这种可访问性概念的需要,也可以给复杂的浮动布局带来方便。

 

但是由于 layout 概念的存在,这种设计理念的效果在IE中就要打个问号了:因为在IE中绝对定位只有当其包含元素拥有 layout 时才会计算正确,而且绝对定位元素的百分比宽度参考也搞错了对象。这里 IE5 和 IE6 的行为不同但都有问题。IE7b2 的行为就要好很多,虽然有些小地方还是有错误。总之尽可能的让绝对元素的包含区块拥有 layout,而且尽量让其就是绝对定位元素的父级元素(也就是说这个包换元素和绝对定位元素之间没有绝对定位元素的别的祖先了)。

 

假设一个无 layout 的父元素被相对定位了——我们就得给它赋予 layout 才能使偏移量起作用:

 

Absolutely Buggy II

http://www.positioniseverything.net/abs_relbugs.html
 

假设一个未定位的父元素需要特定尺寸,而且页面设计是基于百分比宽度的——我们就可以放弃这个想法了,因为浏览器支持不佳:

 

absolutely positioned element and percentage width

http://www.satzansatz.de/cssd/tmp/apboxpercentagewidth.html
滤镜

MS专有的滤镜属性 filter

http://msdn.microsoft.com/workshop/author/filter/filters.asp

是只适用于 layout 元素的。有些滤镜扩展了对象的边界。它们会显示出自身特有的缺陷。

http://www.satzansatz.de/cssd/tmp/alphatransparency.html
对已渲染元素的重排(re-flow)

当所有元素都已渲染完成时,如果有一个因鼠标经过而引起的变化产生(比如某个链接的 background 有变化),IE会对其 layout 包含区块进行重排。有时一些元素就会因此被排到了新的位置,因为当这个鼠标经过发生时,IE已经知道了所有相关元素的宽度、偏移量等数据了。这在文档首次 载入时则不会发生,那时由于自动扩张的特性,宽度还无法确定。这种情况会导致在鼠标经过时页面出现跳变。

 

Jump on :hover

http://www.satzansatz.de/cssd/pseudocss.html#hoverjump

quirky percentages: the reflow

http://www.positioniseverything.net/explorer/percentages.html
 

这些和重排问题相关的 bug 会给百分比边距和补白使用较多的流动布局带来不少麻烦。


背景原点

MS专有的这个 hasLayout 还会影响背景的定位和扩展。比如,根据 CSS 规范,

http://www.w3.org/TR/CSS21/colors.html#q2background-position

: 0 0 应该指元素的“补白边缘(padding edge)”。而在 IE/Win 下,如果 hasLayout = false 则指的是“边框边缘(border edge)”,当 hasLayout=true 时指的才是补白边缘:

 

Background, Border, hasLayout

http://www.brunildo.org/test/BackgroundBorderLayout.html

边距重叠

hasLayout 会影响一个盒子和其子孙的边距重叠。根据规范,一个盒子如果没有上补白和上边框,那么它的上边距应该和其文档流中的第一个孩子元素的上边距重叠:

 

Collapsing Margins

http://www.w3.org/TR/CSS21/box.html#collapsing-margins

Uncollapsing Margins

http://complexspiral.com/publications/uncollapsing-margins
 

在 IE/Win 中如果这个盒子有 layout 那么这种现象就不会发生了:似乎拥有 layout 会阻止其孩子的边距伸出包含容器之外。此外当 hasLayout = true 时,不论包含容器还是孩子元素,都会有边距计算错误的问题出现。

 

Margin collapsing and hasLayout

http://www.brunildo.org/test/IEMarginCollapseLayout.html

块级别的链接

hasLayout 会影响一个块级别链接的鼠标响应区域(可点击区域)。通常 hasLayout = false 时只有文字覆盖区域才能响应。而 hasLayout = true 则整个块状区域都可响应。添加了 onclick/onmouseover 等事件的任意块级元素也有同样的现象。

 

Block anchors and hasLayout

http://www.brunildo.org/test/IEABlock1.html

在页面内使用键盘浏览:探索中

当使用 tab 在页面中浏览时,如果进入了一个页内链接(in-page link),那么接下来再按的 tab 键就不会正常继续了:

 

hasLayout Property Characterizes IE6 Bug

http://jimthatcher.com/news.htm#haslayout

Keyboard Navigation and Internet Explorer

http://juicystudio.com/article/ie-keyboard-navigation.php

tab 键会把用户带到(这通常是错误的)其最近的 layout 祖先中的第一个目标(如果这个祖先是由 table, div, span 或某些别的标签构成)。



收缩包围(shrink-wrapping)现象

给已经有 width: auto 的元素添加某些属性会导致它们在计算自身宽度时使用一种收缩包围的算法。比如这些属性 float: left|right, position: absolute|fixed, display: table|table-cell|inline-block|inline-table.

 

这些属性造成的现象在IE/Win中也存在,当然这是只对那些它支持的属性而言。但是当一个应该收缩包围的元素中包含一个拥有“layout”的块级元素时,在绝大多数情况下,这个孩子元素的宽度会尽可能地扩展而与其中包含的内容无关,同时也阻止了父元素的收缩包围现象。

 

例子:

http://dev.l-c-n.com/IEW2-bugs/shrinkwrap.php

一个浮动的纵向导航无序列表并没有收缩包围,因为其中的链接为了消除列表的多余空白bug并扩展可点击区域而拥有了 layout:a {display: block; zoom: 1;}。


 

这时收缩包围现象只有在以下情况仍然有效:拥有 layout 的孩子元素同时也被赋予了一个特定宽度,或者这个孩子元素本身也是一个具有收缩包围特性的元素,比如浮动元素。


边缘裁切

通常而言,当一个盒子包含了诸如伸出其边缘的内容这种更复杂的结构时,这个容器就经常需要“hasLayout”来避免一些渲染错误。但使用这种常用方法又会在边界处理时左右为难,因为一个获得“layout”的元素会变成某种自封闭的盒子。

 

内部的内容盒子会被裁切,比如使用负边距向外移动时。

 

Clipping of negative margined blocks in a hasLayout container

http://dev.l-c-n.com/IEW2-bugs/min-width-clip.php
 

被裁掉的部分当内容盒子触发了“layout”时可以再次出现,但在 IE6 中需要同时拥有 position: relative 才行。IE7 在这方面要略有改观,它不再需要额外的 position: relative 了。





堆叠,分层和 layout

 

IE/Win 中似乎有两种分层和堆叠顺序:

 

一种是(伪)试图采用CSS的模式:Effect of z-index value to RP and AP blocks

http://www.aplus.co.yu/css/z-pos/

还有一种是由“hasLayout”及其孪生兄弟“contenteditable”的行为产生的堆叠顺序。正如在上面相对定位的例子中展现的那样,在 layout 影响下的堆叠现象就好像 Harry Houdini (译者注:魔术师,以纸牌魔术成名)的拿手戏法儿一样。


 

两种堆叠模式虽互不相容,但却共存于IE的渲染引擎中。经验之谈:调试的时候,两种情况都要考虑到。我们可能会有规律地在下拉菜单或者类似的复杂菜单中看 到相关问题,因为它们往往牵涉到堆叠,定位和浮动等诸多令人头疼的问题。给那些 z-index 定位的元素 layout 是一种可能的修正方法,不过也不限于此,这里只是提醒一下。

 

混乱的 contenteditable

 

如果给一个 HTML 标签设定 contenteditable=true 属性,比如,将会允许对该元素以及其 layout 子元素进行实时的编辑、拖动改变尺寸等操作。你可以把这属性用在浮动元素或者一个有序列表中的 layout 列表元素上看看效果。

 

为了对元素进行操作(编辑它们),“contenteditable”和“hasLayout”为那些 hasLayout 返回 true 的元素引入了一套单独的堆叠顺序。

 

Editing Platform

http://msdn.microsoft.com/librar ... mshtmleditplatf.asp

继承了 layout 概念,对 layout 的误解多是因 contenteditable 而起即可作为证明(那些某种程度上集成了IE编辑引擎的应用软件多暗含着对layout概念的某种强制向后兼容性)。

 

More on contenteditable

http://annevankesteren.nl/2005/07/more-contenteditable



和 CSS 规范类似的地方


 

你的 MSIE 页面在别的浏览器中一团糟?我们可没必要让这种事情发生。如果使用恰当,任何好的浏览器都能摆平 MSIE 的页面——只要你使用一些正确的 CSS。

 

利用 hasLayout 和“新的块级格式化范围”http://www.w3.org/TR/CSS21/visuren.html#q15之间的细微相似之处,我们可以有几种 方法在标准兼容浏览器中重新实现 hasLayout 的“包含浮动元素”http://www.w3.org/TR/CSS21/visudet.html#root-height效果,和一些“浮动元素旁 边的元素”http://www.w3.org/TR/CSS21/visuren.html#floats所特有的效果。

 

Reverse engineering series

http://www.gunlaug.no/contents/wd_example_01.html

Simulations

http://dev.l-c-n.com/IEW/simulations.php


Quirks 模式

 

关于这种渲染模式的的信息,请参考我们的 quirks 模式

http://www.satzansatz.de/cssd/quirksmode.html

章节。

 

Layout ——结论

 

整个 layout 概念和一些基本 CSS 概念是不兼容的,即包含,排列,浮动,定位和层叠等。

 

由于页面中元素或有或没有 layout,会导致 IE/Win 的行为和 CSS 规范相违背。





拥有 layout ——另外一个引擎?


 

IE 的对象模型看起来是文档模型和他们传统的应用程序模型的糅合。我之所以提到这点是因为它对于理解IE如何渲染页面很重要。而从文档模型切换到应用程序模型的开关就是给一个元素“layout”。



(Dean Edwards)
 

有时候要解释清楚某种行为是不可能的:就比如 hasLayout,会根据它的状态选择两种不同渲染引擎的一种使用,而且每一种都有其自己的 bug 和怪异之处。





不可消除的 bug


 

软件 bug 是由于在制作过程中对完整性和逻辑问题考虑不周等人为错误而导致的。这是人类的固有缺陷,目前还没有什么好的解决方法。

 

同样由于这种缺陷,任何试图不重写软件而修复 bug 的做法,都将会不可避免的导致软件中出现更复杂的bug。

 

所有依赖别的软件的软件——当然包括依赖操作系统,也会同样依赖他们的 bug。于是我们会从所有关联的软件中得到一连串的 bug,这也更说明找到一个无 bug 软件是几乎不可能的。