【分享】Firefox中table元素的绝对定位子元素包含块判定错误的bug
关于绝对定位元素的定位，依赖于其包含块。也就是说，当绝对定位元素的"top"、"left"值被设置之后，绝对定位元素会根据这两个值，相对于其包含块产生位移。见：http://www.w3.org/TR/CSS2/visuren.html#absolute-positioning

关于包含块的概念，在帖子：【分享】说说标准 -- 可视化格式模型(visual formatting model)之一 -- 包含块(containing block)已经做了详细的说明，其中，W3C CSS2.1规范中规定，绝对定位元素的包含块(containing block)，由离它最近的position特性值是"absolute"、"fixed"、"relative"之一的祖先元素组成；如果这个祖先元素不存在，则包含块是初始包含块。

但是，这个规则在Firefox里好像不大管用。

本来想做一个很华丽丽的效果，需要把一个绚丽的图片针对表格的左上角定位，，本来在其他浏览器中好好的，但是到Firefox中就不灵了……

HTML code

<div style="width:200px; height:200px; position:absolute; background-color:silver;">
   <table style="position:absolute; width:100px; height:100px; top:100px; left:100px; background-color:green;">
       <tr>
               <td>
                       <div style="position:absolute; width:50px; height:50px; top:50px; left:50px; background-color: gold;">
                               TEXT
                        </div>
               </td>
       </tr>
    </table>
</div>

本来是要想让金色的绝对定位 DIV 相对于 TABLE 来定位，但事与愿违，在 Firefox 里，变成了这样：

金色的 DIV 没有相对于绿色 TABLE 的左上角定位，跑偏了，相对于灰色的 DIV 定位了，当TABLE 不存在，哈！

其他浏览器中，就这样子：

可见，在Firefox中，TABLE 中好像创建不了包含块。
所以，在Firefox里，绝对定位元素的包含块是"position"特性值为"absolute"、"fixed"、"relative"之一的非table类型的祖先元素。定位的时候，也就会出现意想不到的效果。

这个问题，还可能会影响绝对定位元素的自动宽度计算。

所以，想相对于 TABLE 元素定位的同学小心了。


更多兼容性问题：【分享】浏览器兼容性问题目录






------解决方案--------------------
　　我在楼主的很多帖子里都说过,BUG不是随便可以说的.问题在于你是否先弄明白了这款产品的使用说明书.
　　不同的产品,对于细节的处理,有各自的观念和定义.那是它的规矩,你要用,就必须遵循.
　　TABLE侧重于对其内部内容的组织管理.DIV侧重于版块布局的控制.
　　作为FF,把display:table的元素作为内容处理,可以简化和清晰控制结构,也是很合理的.
　　无论是IE,还是FF,真正的BUG只是少数,更多的差异,是他们的匠心所至.若不理解其苦心,反动不动就说是BUG,实在也是不尊重别人的劳动和用心.毕竟如果全都遵循一种最原始简单的规范,就可以少做很多工作,当然,不排除有竞争的动机使然,说到这个,其实也都一样.而且,没有任何设计和决定能够满足所有要求,这是定理.
　　一个成手,应该是能够理解制作者的考虑.这是一个境界问题,源于经验.在那之前,才总是满腔疑虑,甚至忘了应该先去学习用法规矩而去做无谓的抱怨.
　　楼主作为这里的版主，年轻固然不错，但也要明白责任．与其动不动今天炮轰IE的BUG明天炮轰FF的BUG（其实我也希望看到真正的BUG，但大多都不是，所以也更失望），不如先去查找到相关的各方面资料，思考之后再决定怎么说，或者是从理解的角度去说明为什么有这样的差异－－毕竟现实已经存在，毫无意义的抱怨BUG于事无补，理解存在的为什么合理，才能于人于己更好地生活和工作．
　　当然,我在这里说的话,对于楼主来说,虽然是逆耳良言,但现实就是那样,往往不能真正落好.以前碰过很多人就是这样,虽然因为我的话而改变了行为方法,但对我却留下记恨.无论怎样,我不在乎,我只奉行自己的行事风格罢了,劝人说事,乐本当为,若图回报,则失吾心.楼主自处吧.
------解决方案--------------------

探讨

　　我在楼主的很多帖子里都说过,BUG不是随便可以说的.问题在于你是否先弄明白了这款产品的使用说明书.
不同的产品,对于细节的处理,有各自的观念和定义.那是它的规矩,你要用,就必须遵循.

------解决方案--------------------

探讨

作为FF,把display:table的元素作为内容处理,可以简化和清晰控制结构,也是很合理的.

------解决方案--------------------
呵呵，此帖最大亮点是楼上的楼上的楼上两贴。

也许楼主把所有的“bug”都替换为“差异”才能保证自己说的都是“正确”的。
又或许干脆和一些隐居在民间的高手一样，来个“羚羊挂角”，让人无迹可寻，阿弥陀佛，不可说不可说……

“bug”的确很难界定，有无相生，难易相成，那谁和“bug”呼应呢？造成 Crash 的代码？考虑不周导致的意料之外的问题？又或是选择性忽略的问题？

不同角色的人对“bug”的敏感程度不同，用户把它当作一个标签，认为不符合常理的现象就是“bug”。开发者把“bug”看作一个危险讯号，认为在代码级别的意料之外，才算是“bug”。

记得曾有过“IE盒模型Bug”的说法，这个就是广大用户从自己取的名字，而不是微软官方的称谓。但这并不妨碍大家理解这个问题。

当然，当然为了避免误导读者或者产生其他不必要的歧义，楼主的确可以少用“bug”这类字眼。

比如去餐厅，服务员上来了水，你一喝，tmd，怎么是牙膏味，想吐，于是扔在一边不再喝。
然后你和其他朋友说“我去了家饭馆，他家的水是tm牙膏味，我喝的想吐。”
或者说“我去了家饭馆，他家的水很有特色，嗯，和其他饭馆的味道有差异。”

前者太主观了，后者更加负责。
也许这个餐厅的水是纳米抗菌远红外RNA螺旋藻的薄荷水，对健康有好处呢……

不知各位喜欢那种说法？

PS: 看了楼主很多文章，受益匪浅，大家也看得出来，这贴是专门的挺一下楼主，呵呵。