The analysis and solution of flexible.js font size and its strange phenomenon

When I recently made a mobile-phone page, I encountered a strange problem: The font display size is inconsistent with the size specified in the CSS. You can view this demo (remember to open chrome DevTools).

As shown, you can find that the originally specified font size is 24px, but the final calculation is 53px, see this bizarre result, my heart cursed a sentence: What a ghost!

Then began to troubleshoot the problem: A label caused? One of the CSS causes? Or a certain sentence JS code caused by. Through a lump of the deletion code, found that seemingly are not. I can't help but scold, what the hell! However, there are some clues in the middle: when the number of labels or the number of text in a page is greater than a certain value, or when the font size of the CSS definition falls within a certain interval, the problem is triggered. Also, the value of the font becomes larger and changes with the original defined font size.

Then nature is a variety of search, finally have a new discovery. Originally this feature is called to do "text autosizer", also known as "font boosting", "font inflation", is Webkit to the mobile browser provides a feature: when we browse the Web on the phone, it is likely because the original page width is large, When you zoom out on your phone screen, you can't see the text. And the font boosting feature at this point will automatically be the text font size, to ensure that there is no need to swipe left and right, and do not need to double-click to enlarge the screen content, but also allows people to easily read the text on the page.

However, this feature is not always necessary, it is good to find the cause of the problem at the same time, we also discussed the problem of some of the treatment options:

1. Specified manually viewport width=320 , the Font boosting will not be triggered. (You can see later, this statement is not rigorous, when the other settings are the default value, this article is valid)
2. Font boosting only works in an unqualified text stream, specifying a wide height for the element to prevent the font boosting from being triggered.
3. Obviously the 2nd option is flawed, and the text content cannot all be specified as wide. But fortunately, we pass the designation max-height , min-height min-width max-width ,, (after @Ovaldi correct, max-height only valid) is also possible. For example body * { max-height: 999999px; } , you can disable the Font boosting feature without side effects. Of course, I don't think it's necessary to use a generic selector, which p { max-height: 999999px; } might be better with a similar.

Here, we understand the problem, and there are solutions. But one problem still bothers me: when the font is larger than a certain value (such as when the viewport width is not specified, the phone screen width=320, the font is greater than or equal to 82px), the font boosting will never be triggered. What is the logic of how Chrome is calculated?

This time the problem is not so easy to solve, I first a variety of search without fruit, and then their own human flesh to try, slowly find the law, but found that the change is not linear, it seems that the formula is more complex. Finally today I found this article: Chromium's Text Autosizer, thoroughly explaining my doubts.

Font boosting specific implementation code in the TextAutosizer.cpp this file can be seen, interested can be doubled.

In short, the calculation rule pseudocode for the Font boosting is as follows:

Multiplier=Math.Max1, Devicescaleadjustment* Textscalingslider* Systemfontscale* Clusterwidth/screenwidth);if (originfontsize<(+) {Computedfontsize= originfontsize * multiplier;} else if (16 <= originFontSize <= (32 * multiplier - 16)) {computedfontsize = (originfontsize /2) + (16 * multiplier -8);} else if (originfontsize > (32 * multiplier -16)) {computedfontsize = originfontsize;}                

The variable name is explained below, and a more specific description can refer to the top two links.

• originFontSize: Original Font size
• computedFontSize: The calculated font size
• multiplier: conversion factor, values are calculated from the following values
  • deviceScaleAdjustment: viewport width=device-width This value is 1 when specified, otherwise the value is between 1.05-1.3 and there is a specific calculation rule
  • textScalingSlider: Manually specified zoom ratio in the browser, default to 1
  • systemFontScale: System font size, Android device can be set at "device-display-font size", default to 1
  • clusterWidth: The width of the element where the font boosting attribute is applied (how to determine this element refer to the top two links)
  • screenWidth: Device screen resolution (DIPs, Density-independent Pixels), such as IPhone 5 for 320

Said so much, seemingly just need to remember p { max-height: 999999px; } on the OK ... -_-!!!

max-height: 100%it might be better to use it.

WebKit should have a judgment if initial-scale=1 , when not triggering the font boosting.

<name="viewportcontent=" width=device-width, initial-scale=1"><!--or- <name ="Viewportcontent =" initial-scale=1, maximum-scale=1, minimum-scale=1"> 

The analysis and solution of flexible.js font size and its strange phenomenon