css - REM 字体大小未调整到任意阈值以下

Question

在 Mac Mojave 10.14.2 上的 Safari 12.0.2 和 Chrome 71.0.3578.98 中，当使用 rem 单位设置 font-size 时，实际大小不会低于 9px。

看这个例子:

https://codepen.io/stephenjwatkins/pen/OrbGxL

我的浏览器的字体大小设置为默认值 (16px)，最小字体大小设置为 6px:

将 text-size-adjust 设置为 none 不会影响该问题。 Firefox 正确呈现大小。

我发现唯一可以解决此问题的方法是将 font-size: 0; 设置为父元素。例如，如果您将 font-size: 0; 添加到 .container，则会呈现正确的字体大小。

有谁知道为什么它不遵守低于特定阈值的 rem 大小？

Answer 1

Chrome 及其 Blink 渲染引擎似乎有一些不明显的字体缩放规则。我不知道有任何正式的综合文档，所以让我们去源代码吧。

(请注意，我不是 Chromium 内部结构方面的专家，尤其是 Blink 渲染器方面的专家。我只是一直在跟踪源代码并推测所提出问题的最可能答案。)

在我看来，引擎调用了 the FontBuilder class在重绘期间。这个类有各种调度方法，将 DOM、缩放和其他相关因素传递到看似关键的方法中:FontSize :: getComputedSizeFromSpecifiedSize .在这种方法中，我们看到了一些有趣的评论来解决您提出的问题:

<强>1。为什么将 font-size: 0; 设置为父元素可以修复它？

  // Text with a 0px font size should not be visible and therefore needs to be
  // exempt from minimum font size rules. Acid3 relies on this for pixel-perfect
  // rendering. This is also compatible with other browsers that have minimum
  // font size settings (e.g. Firefox).

<强>2。为什么它不接受低于特定阈值的 rem 大小？

  // We support two types of minimum font size. The first is a hard override
  // that applies to all fonts. This is "minSize." The second type of minimum
  // font size is a "smart minimum" that is applied only when the Web page can't
  // know what size it really asked for, e.g., when it uses logical sizes like
  // "small" or expresses the font-size as a percentage of the user's default
  // font setting.

  // With the smart minimum, we never want to get smaller than the minimum font
  // size to keep fonts readable. However we always allow the page to set an
  // explicit pixel size that is smaller, since sites will mis-render otherwise
  // (e.g., http://www.gamespot.com with a 9px minimum).

<强>3。出于好奇，当给定相对单位(例如 x-small)时，这些最小值是多少？

// Strict mode table matches MacIE and Mozilla's settings exactly.
static const int strictFontSizeTable[fontSizeTableMax - fontSizeTableMin +
                                     1][totalKeywords] = {
    {9, 9, 9, 9, 11, 14, 18, 27},    {9, 9, 9, 10, 12, 15, 20, 30},
    {9, 9, 10, 11, 13, 17, 22, 33},  {9, 9, 10, 12, 14, 18, 24, 36},
    {9, 10, 12, 13, 16, 20, 26, 39},  // fixed font default (13)
    {9, 10, 12, 14, 17, 21, 28, 42}, {9, 10, 13, 15, 18, 23, 30, 45},
    {9, 10, 13, 16, 18, 24, 32, 48}  // proportional font default (16)
};
// HTML       1      2      3      4      5      6      7
// CSS  xxs   xs     s      m      l     xl     xxl
//                          |
//                      user pref

有趣的是，FontBuilder 类调度到 TextAutosizer :: computeAutosizedFontSize缩放字体大小。此方法使用硬编码值和可变比例因子:

  // Somewhat arbitrary "pleasant" font size.
  const float pleasantSize = 16;
  // Multiply fonts that the page author has specified to be larger than
  // pleasantSize by less and less, until huge fonts are not increased at all.
  // For specifiedSize between 0 and pleasantSize we directly apply the
  // multiplier; hence for specifiedSize == pleasantSize, computedSize will be
  // multiplier * pleasantSize. For greater specifiedSizes we want to
  // gradually fade out the multiplier, so for every 1px increase in
  // specifiedSize beyond pleasantSize we will only increase computedSize
  // by gradientAfterPleasantSize px until we meet the
  // computedSize = specifiedSize line, after which we stay on that line (so
  // then every 1px increase in specifiedSize increases computedSize by 1px).
  const float gradientAfterPleasantSize = 0.5;

从这些事实中，我们看到有大量的硬编码像素值，9 和 16 通常散布在相关代码中。这些硬代码、将字体缩小到极限的若干规则的存在，以及使用字体大小覆盖的能力，所有这些似乎都符合观察结果，并表明它的行为符合预期——即使不一定是直观的。

---

此外，我发现最近的评论发布在 Chrome bug #319623 中与您的报告非常相似。

Possibly related: when using relative units on the html tag, rem-based values defined elsewhere will have a lower bound of 9px.

See CodePen: http://codepen.io/larrybotha/pen/wKYYXE

Workaround: absolute unit on html, em unit on body. rems everywhere else.

观察该错误以进一步发展可能是谨慎的，尽管可能不会屏住呼吸。最后一次更新是在 2015 年。