(我调整了这个图片中的块元素的位置 – 保持基线一致 – 以说明大小和文本定位的差异).如果你有Mac,你可以看到我在说的是in this JS Bin.
现在,我对如何解决这个特定的差异没有直接的兴趣.我意识到有hand-tuned reset stylesheets试图消除或论证差异,但是我对这些浏览器首先渲染不同的因素特别感兴趣.
我在这里做一些假设：
>标准存在于字体的呈现以及标准框模型中的字形的大小和位置,但是在它们如何交互方面可能是未指定的.
>浏览器制造者对上述标准的解释存在错误,这可能会影响文本的大小,位置和渲染方式.
>对于这些特定的浏览器,大部分设计讨论和实际实现都是以某种形式公开的.因此,如果有人知道在哪里看,可以了解这种差异的根源.
>两个浏览器都在同一个地方开始 – 标记,样式和字体定义在它们之间是一致的.在某种程度上,他们在如何使用这些产品来产生最终产出方面分歧.
因此,我的具体问题是：在这个过程中哪里发生这种分歧,什么原因导致它发生？
我觉得,凭借这种知识,我可以更好地理解如何纠正这种差异.在这种情况下,特别是在类似的情况下,我将来可能会遇到.
解决方法
The height of the content area should be based on the font,but this specification does not specify how. A UA may,e.g.,use the em-Box or the maximum ascender and descender of the font. (The latter would ensure that glyphs with parts above or below the em-Box still fall within the content area,but leads to differently sized Boxes for different fonts; the former would ensure authors can control background styling relative to the ‘line-height’,but leads to glyphs painting outside their content area.)
换句话说,排版,以及如何绘制和定位行框的内容区域,由浏览器自己的实现决定,至少在CSS2.1中.然而,这可能在未来的规范中更好地定义(可能是Fonts module,如果不是单独的模块1).
Section 10.8.1包含一些关于line-height属性如何影响内联文本的内容区域的呈现的细节,但又取决于内容区域本身的高度,如上所述,CSS2.1中未定义.
请注意,auto不是line-height的有效值;你可能意图使用正常,这也是它的初始值(但不一定是浏览器默认).此外,这是规范对价值正常的说明：
normal
Tells user agents to set the used value to a “reasonable” value based on the font of the element. The value has the same meaning as . We recommend a used value for ‘normal’ between 1.0 to 1.2. The computed value is ‘normal’.
正如你所看到的,即使对于line-height：normal和line-height：1(或1em或100％)进行比较,因为什么构成“正常”行高是由浏览器决定的决定也一样.然而,Chrome和Firefox看起来像在要求使用正常行高的时候,能够将字形保持在合理的边界内.
顺便说一句,Chrome不会剪下降.它确实使它们在内容框之外,但是不应该将它们剪切到框的边界,除非设置overflow：hidden.
1 line-height属性的CSS3定义目前驻留在this module,但很明显,它已被遗弃,或至少等待重写.目前状态下的模块非常详细,但足以说,浏览器供应商和工作组几乎被忽略.
