Firefox为什么将Helvetica与Chrome区别对待? [英] Why does Firefox treat Helvetica differently from Chrome?
问题描述
在Helvetica中呈现的文本的垂直位置及其内容区域的大小在Firefox和Mac版Chrome上有所不同.例如，在Chrome浏览器中，如果行高与字体大小相同，则会裁剪降序显示.
The vertical position of text rendered in Helvetica and the size of its content area differ between Firefox and Chrome for Mac. For example, in Chrome, the descenders are clipped if the line-height is identical to font-size.
(我已经调整了图片中块元素的位置(保持基线一致，以说明大小和文本位置的差异)).如果您使用的是Mac，则可以在此JS Bin 中看到我在说什么.
(I’ve adjusted the position of the block elements in this picture—keeping the baseline consistent—to illustrate the difference in size and text positioning). If you have a Mac, you can see what I’m talking about in this JS Bin.
现在，我对如何解决这一特定差异并不直接感兴趣.我意识到有手动调整的重置样式表，它们试图消除或覆盖差异，但我对引起这些浏览器首先呈现不同效果的因素特别感兴趣.
Now, I'm not directly interested in how to fix this specific discrepancy. I realize there are hand-tuned reset stylesheets that attempt to eliminate or paper-over the differences, but I'm specifically interested in the factors that caused these browsers to render differently in the first place.
我在这里做一些假设:
-
在标准框模型中既存在字体的呈现方式又存在字形的大小和位置的标准，但是在它们如何交互方面可能未指定.
Standards exist for both the rendering of fonts and the sizing and positioning of glyphs within the standard box model, but may be unspecified in terms of how they interact.
浏览器制造商对上述标准的解释中存在错误，这可能会影响文本的大小，位置和呈现方式.
Bugs exist in browser-makers interpretations of the aforementioned standards, which may influence how text is sized, positioned and rendered.
对于这些特定的浏览器，许多设计讨论和实际实现都是以某种形式公开的.因此，如果知道在哪里看，就有可能了解这种差异的根源.
For these specific browsers, much of the design discussion and actual implementation is public in some form. Therefore, it is possible to learn the source of such discrepancies, if one knows where to look.
两个浏览器都在同一位置启动-标记，样式和字体定义在它们之间是一致的.在某些时候，他们在如何使用它们来产生最终输出方面存在分歧.
Both browsers start in the same place - the markup, styles and font definitions are consistent between them. At some point, they diverge in how they use these to produce the final output.
因此，我的具体问题是: 在该过程中的哪里出现，并且什么导致了它发生?
Therefore, my specific question is: where in the process does this divergence occur, and what causes it to occur?
我认为，有了这些知识，我就能更好地理解如何纠正这种差异.特别是在这种情况下，以及在以后可能遇到的类似情况下.
I feel that, armed with this knowledge, I can better understand how to correct for such discrepancies. Both in this case specifically, and in similar situations that I may encounter in the future.
推荐答案
Unfortunately, re: rendering of the content area based on the font, CSS2.1 does not say much at all:
内容区域的高度应基于字体，但是此规范未指定如何.UA可以例如使用字体的em-box或最大升序和降序.(后者将确保在em-box上方或下方具有部分文字的字形仍位于内容区域内，但导致不同字体的大小不同的框；前者将确保作者可以控制相对于'line-height'的背景样式.，但导致字形在其内容区域之外绘画.)
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中，排版以及如何精确地绘制和定位线框的内容区域取决于浏览器自己的实现.但是，在以后的规范中可能会更好地进行定义(可能不是字体模块单独的模块 1 ).
In other words, typesetting, and how exactly to draw and position the content area of a line box, is left up to the browser's own implementation, at least in CSS2.1. This may however be better defined in a future specification (likely the Fonts module, if not a separate module1).
第10.8.1节包含有关 line-height 属性会影响内联流文本周围内容区域的呈现，但同样取决于内容区域本身的高度，如上所述，CSS2.1中未定义该高度.
Section 10.8.1 contains some details on how the line-height property affects the rendering of the content area around text that flows inline, but again it depends on the height of the content area itself, which as stated above is undefined in CSS2.1.
请注意， auto 不是 line-height 的有效值；您可能打算使用 normal ，这也是它的初始值(但不一定是浏览器的默认值).另外，这就是规范对值 normal 的说明:
Note that auto is not a valid value for line-height; you probably meant to use normal, which incidentally is also its initial value (but not necessarily the browser default). Also, this is what the spec says about the value normal:
正常
告诉用户代理根据元素的字体将使用的值设置为合理"的值.该值与的含义相同.我们建议正常"的使用值介于1.0到1.2之间.计算出的值为正常".
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看起来可以很好地将字形保持在合理的范围内.
As you can see, there's not much to go on, even with regards to comparing line-height: normal and line-height: 1 (or 1em or 100%), because what constitutes a "normal" line height is up to the browser to decide as well. However, it looks like Chrome and Firefox do a good job of keeping glyphs within reasonable boundaries when asked to use a normal line height.
顺便说一句，Chrome不会 overflow:hidden .
By the way, Chrome does not clip the descenders. It does render them outside of the content box, but it should never clip them to the bounds of the box unless you set overflow: hidden.
1 A CSS3 definition of the line-height property currently resides in this module, but it's immediately obvious that it's been long abandoned, or at least pending a rewrite. The module in its current state is extremely detailed, but suffice it to say that it's been largely ignored by both browser vendors and the working group.
这篇关于Firefox为什么将Helvetica与Chrome区别对待?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
