html 字体大小最小值,css – REM字体大小未调整到低于任意阈值

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-小)时,这些最小值是多少？

// 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通常是关于相关代码的.这些硬代码,将字体缩小到极限的几个规则的存在,以及使用font-size覆盖的能力似乎都与观察结果相符,并表明它的行为符合预期 – 如果不一定是直观的.

此外,我发现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: 07004

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

谨慎观察这个进一步发展的错误,尽管可能没有屏住呼吸.最后一次更新是在2015年.