常见问题与规范文档细节探寻.ppt

常见问题与规范文档细节探寻 拨开 BUG 迷雾 2010 12貘w3help org IE6 7下文字断头断脚问题webkit断脚问题 chrome10 0 612 3dev修复 IMG下的间隙思考 同行的表单元素怎么对齐relative被父容器裁断了IE数组内最后一个逗号的问题 非IE9 ChromeOpera IE9 中for in遍历对象属性的顺序 一些常见问题 相同原因导致 相同原因导致 IE6 7文字断头断脚A webkit下的 断脚 AAA 奇怪的间隙 换个常用DOCTYPE看看 通常情况下可以理解为中文的文字底边处于baseline位置文字顶部处于行内框顶部 仅中文存在的情况下 文字底边线与baseline位置重合 top与bottom之间为inlinebox高度 即是line height设置值 不含替换元素 正常情况下的inlinebox布局结构 实际情况其实很复杂 不同的字体为文字预留的上下划线高度不同 会导致文字顶部和底部留有不同高度的空隙 这就是设计值与实际值不同的情况 其余情况下inlinebox可能呈现的布局结构 需要注意 leading是font size与line height的差值 half leading是这个差值的一半 分别填充在文字上下方 这就出现了问题 假设差值是个奇数9px 那么是上下填充5px 4px呢 还是4px 5px呢 规范里没有明确说明 这就造成了不同浏览器再细节上的处理差异 其余情况下inlinebox可能呈现的布局结构 文字溢出inlinebox时half leading为负值 这不影响布局 溢出的文字可能会产生重叠 细节信息可查看CSS2 1规范10Visualformattingmodeldetails10 8 1Leadingandhalf leadinghttp www w3 org TR CSS21 visudet html leading marginpaddingborder都去哪里了 需要注意 不同字体为文字预留的上下划线空隙不等 1 2px 因此文字的字体绝对顶边和底边大部分情况下与布局盒的contentbox顶底有距离 maringpaddingborder都不加入行内框高度的计算 也就不参加行框高度的计算 它们还是在行内框周围得到渲染 这就意味着如果 一组行内框在垂直方向生成了多个行框 一个行框的高度小其中某个行内框的border边界 background以及border可能会 渗入 会垂直方向相邻的行框 marginpaddingborder都去哪里了 规范的演变造成陷阱 CSS2 0中说明当行内框溢出行框时 有些客户端可能会使用行框 linebox 来 剪裁 不渲染 溢出的部分 CSS2 1中确替换成客户端应根据文档顺序来渲染这些行内框 这将使得后面的框会覆盖在前面的框之上 好吧 现行规范把 剪裁 的事情抛弃了 这说明任何在CSS2 1版本发布前就开始开发的浏览器出现文字断头断脚现象是正常的 它不是bug 行内替换元素的inlinebox布局结构 在没有设置宽高的情况下 元素就存在内在宽高 非浏览器默认样式给出的宽高 这就是替换元素 常见的替换元素有IMGIFRAMEINPUTSELECTBUTTON TABLE是否属于替换元素 这存在争议 仅从存在默认宽高的角度来讲 它不属于替换元素范畴 但是在此处TABLE和inline block后的元素 在此处均是遵循行内替换元素布局的 linebox的布局 看看规范是怎么说 关于LineHeight 行高 计算说明 请参照W3CCSS2 1规范10 8节 http www w3 org TR CSS21 visudet html line height关于Leadingandhalf leading 差异半差异 说明 请参照W3CCSS2 1规范10 8 1节 http www w3 org TR CSS21 visudet html leading关于Inlineformattingcontext 行内格式化上下文 说明 请参照W3CCSS2 1规范9 4 2节 http www w3 org TR CSS21 visuren html inline formatting关于 line height 特性说明 请参照W3CCSS2 1规范 http www w3 org TR CSS21 visudet html propdef line height关于 vertical align 特性说明 请参照W3CCSS2 1规范 http www w3 org TR CSS21 visudet html propdef vertical align 汇总下就是 每一个行内元素会产生一个行内框 行内框会在行框内横向排列 line height 特性值指定了每个行内非替换元素生成的行内框的确切高度 行内替换元素的高度由 height 特性值决定 文字在行内框中垂直排列 上下空隙用半差异填补 如果字号大于行内框则文字从上下方向上溢出行内框 并可能渗入到其他行框内 行框是永远不会重叠的 vertical align 特性值指定了每个行内框的垂直对齐方式 行框的顶边界是这一系列垂直对齐的行内框最高的顶边框 底边界是最低的底边框 行框的高度是顶边界到底边界的距离 linebox的布局结构 linebox的初始布局结构是由容器元素设置的font sizeline height提供 简单的讲 他就像在行框最开始插入了一个零宽的匿名行内元素 由这个元素确定了行框初始基线位置以及middle位置 并且决定了行框高度的最小值 linebox的布局结构 linebox的布局结构 containingblock的布局结构 height auto contentarea top contentarea bottom 自动换行的布局结构 height auto inlinebox contentarea top contentarea bottom 行内非替换元素的行内框可以被打破 产生换行 relative被父容器裁断了 溢出父容器的position relative部分应该受overflow hidden影响么 IE6IE7不受影响 这又是bug么 relative被父容器裁断了 position relative在哪个布局状态中存在 CSS2 0开始规定了三种布局状态 他们是 NormalFlow普通 常规 流Floats浮动Absolutepositioning绝对定位 CSS2 0中9 4 3节中是关于Relativepositioning的说明 9 4节是关于NormalFlow的说明 这表示规范中relative是属于NormalFlow内的 因此 布局显示中relative后内容溢出处于NormalFlow中父元素后 由于设置了overflow hidden特性而被裁断是正确的 CSS1 0的最后一个版本 1996年12月17至2008年4月11日 http www w3 org TR CSS1 CSS2 0第一个推荐版本 1998年3月24日 http www w3 org TR 1998 PR CSS2 19980324 relative被父容器裁断了 在CSS1中 没有提及这三种布局状态 也没有position特性设定 那么IE6应该不能识别position系列相关设置 事实上 在早期版本的MSDN中可以找到position系列相关设置早在IE4 就被支持了 这可能是微软或者网景独创的 NS4 也支持 我所查找的历史资料无法证明谁先谁后 其后才被纳入到规范定义中 因此可以说 IE6IE7中的position relative不是bug而是在其选用的CSS1 0规范 最后修订版本是2008 4 上使用自家布局特性 非2 0规范内说明的position relative 来解释页面 而IE8以后就开始向推荐的CSS2规范靠拢 当然 这个表述是非官方的 仅从浏览器表现现象与规范迭代变更的细节内容参照得出 那IE6IE7的显示方式又是什么问题呢 relative被父容器裁断了 那IE6IE7的显示方式又是什么问题呢 尽管如此我们仍然可以从MSDN现有官方文档中得知IE6IE7实际上是遵循CSS1某个版本规范规范的 比如patMode的返回值CSS1Compat CompatMode是由IE6开始支持 微软大方的间接告诉我们IE用的是CSS1规范 MSDN 0 1 length数组长度是多少 IE6IE7IE8是3ChromeSafari4 Firefox3 IE9是2这是为什么 是IE的bug IE9修复了 IE数组内最后一个逗号的问题 非IE9 IE数组内最后一个逗号的问题 非IE9 ECMAScript规范第三版11 1 4ArrayInitialiser中规定 在以直接量定义数组元素时 在开始 中间和末尾都可以忽略元素 被忽略的元素也会被放入数组中 Arrayelementsmaybeelidedatthebeginning middleorendoftheelementlist WheneveracommaintheelementlistisnotprecededbyanAssignmentExpression i e acommaatthebeginningorafteranothercomma themissingarrayelementcontributestothelengthoftheArrayandincreasestheindexofsubsequentelements ECMAScript规范第五版11 1 4ArrayInitialiser中增加了一条规则 若上述被忽略的元素在数组末尾 则该忽略元素将不被放入数组中 Arrayelementsmaybeelidedatthebeginning middleorendoftheelementlist WheneveracommaintheelementlistisnotprecededbyanAssignmentExpression i e acommaatthebeginningorafteranothercomma themissingarrayelementcontributestothelengthoftheArrayandincreasestheindexofsubsequentelements Elidedarrayelementsarenotdefined Ifanelementiselidedattheendofanarray thatelementdoesnotcontributetothelengthoftheArray IE数组内最后一个逗号的问题 非IE9 ECMAScript规范第三版正式发布于1999年ECMAScript规范第五版正式发布于2009年IE8在2008年开发完成并发布Chrome发布于2008年9月3日并一直在更新FirefoxOpera均在2009年更新过他们的js引擎 真的完全更新了么 Safari的javacriptCore引擎是webkit开源的一部分这些意味着 只有IE8是在ECMAScriptV3规范期间完成的 理应遵守第三版规范 这是规范更替导致的历史问题 并不是IE的Bug 最新版本的IE则顺理成章的使用ECMAScriptV5规范 window onload function varobj city Beijing 12 12 7 7 0 0 2 2 age 15 3 5 3 5 7 7 7 7 online true 3 3 23 23 44 44 info document getElementById info key for keyinobj info innerHTML key obj key ChromeOpera IE9 中for in遍历对象属性的顺序 IE6IE7IE8Firefox3Safari5属性输出顺序与定义时一致 ChromeOpera IE9 中属性输出顺序与定义时顺序不一致 例子中貌似他们很有爱的排序了 这又是IE的bug 那FFSafari凑什么热闹 ECMA 2623rdEdition中12 6 4Thefor inStatement说明for in语句的属性遍历的顺序是由对象自身决定的 Themechanicsofenumeratingtheproperties step5inthefirstalgorithm step6inthesecond isimplementationdependent Theorderofenumerationisdefinedbytheobject Propertiesoftheobjectbeingenumeratedmaybedeletedduringenumeration Ifapropertythathasnotyetbeenvisitedduringenumerationisdeleted thenitwillnotbevisited Ifnewpropertiesareaddedtotheobjectbeingenumeratedduringenumeration thenewlyaddedpropertiesarenotguaranteedtobevisitedintheactiveenumeration ECMA 2625rdEdition中12 6 4Thefor inStatement对for in语句的遍历机制又做了调整 属性遍历的顺序是没有被规定的 Themechanicsandorderofenumeratingtheproperties step6 ainthefirstalgorithm step7 ainthesecond isnotspecified Propertiesoftheobjectbeingenumeratedmaybedeletedduringenumeration Ifapropertythathasnotyetbeenvisitedduringenumerationisdeleted thenitwillnotbevisited Ifnewpropertiesareaddedtotheobjectbeingenumeratedduringenumeration thenewlyaddedpropertiesarenotguaranteedtobevisitedintheactiveenumeration Ch