为什么Firefox对待Helvetica与Chrome不同？

Question

Helvetica中呈现的文本的垂直位置及其内容区域的大小因Firefox和Chrome for Mac而异.例如,在Chrome中,如果行高与font-size相同,则会下移下划线.

(我在这张照片中调整了块元素的位置 - 保持基线一致 - 以说明尺寸和文本定位的差异).如果你有一台Mac,你可以在这个JS Bin中看到我在说什么.

现在,我并没有直接对如何解决这个特定的差异感兴趣.我意识到手动调整的重置样式表试图消除或消除差异,但我特别感兴趣的是导致这些浏览器首先呈现不同的因素.

我在这里做一些假设:

• 对于字体的渲染以及标准盒模型中字形的大小和位置,存在标准,但可能在它们如何交互方面未指定.

• 浏览器制造商对上述标准的解释存在错误,这可能会影响文本的大小,定位和呈现方式.

• 对于这些特定的浏览器,许多设计讨论和实际实现都是以某种形式公开的.因此,如果有人知道在哪里看,就可以了解这种差异的来源.

• 两个浏览器都在同一个地方开始 - 标记,样式和字体定义在它们之间是一致的.在某些时候,他们在如何利用这些产生最终产出方面存在分歧.

因此,我的具体问题是:在这个过程中,这种分歧发生在哪里,是什么导致它发生？

我觉得,凭借这些知识,我可以更好地理解如何纠正这种差异.在这种情况下,特别是在我将来可能遇到的类似情况中.

Answer 1

不幸的是，re：根据字体渲染内容区域，CSS2.1根本没有说太多：

内容区域的高度应基于字体，但本规范没有指定如何。UA可以例如使用em-box或字体的最大上升部分和下降部分。（后者将确保部分位于 em-box 上方或下方的字形仍然落在内容区域内，但会导致不同字体的框大小不同；前者将确保作者可以控制相对于“行高”的背景样式，但会导致字形在其内容区域之外绘制。）

换句话说，排版以及如何准确地绘制和定位行框的内容区域，是由浏览器自己实现的，至少在 CSS2.1 中是这样。然而，这可能会在未来的规范中更好地定义（可能是Fonts 模块，如果不是单独的模块¹）。

第 10.8.1 节包含有关该line-height属性如何影响内联文本周围内容区域的渲染的一些详细信息，但它又取决于内容区域本身的高度，如上所述，这在 CSS2.1 中未定义。

请注意，这不是;auto的有效值。line-height您可能打算使用normal，顺便说一句，这也是它的初始值（但不一定是浏览器默认值）。另外，这是规范中关于该值的说明normal：

正常
告诉用户代理根据元素的字体将使用的值设置为“合理”值。该值与 含义相同。我们建议使用 1.0 到 1.2 之间的“正常”值。计算值是“正常”。

line-height: normal正如您所看到的，即使在比较和line-height: 1（或1em或）方面也没什么可继续的100%，因为什么构成“正常”行高也由浏览器决定。然而，当要求使用正常行高时，Chrome 和 Firefox 似乎很好地将字形保持在合理的边界内。

顺便说一句，Chrome 不会修剪下降部分。它确实将它们呈现在内容框之外，但它永远不应该将它们剪切到框的边界，除非您设置overflow: hidden.

¹ _{该属性的 CSS3 定义line-height当前驻留在该模块中，但很明显它已被长期废弃，或者至少等待重写。该模块当前状态非常详细，但足以说明它在很大程度上被浏览器供应商和工作组忽略了。}