本文是找了在網上搜了好久才找到非常棒的一篇文章,很好的解決了這個問題。
原文地址:https://github.com/amfe/article/issues/10
這個特性被稱做「Text Autosizer」,又稱「Font Boosting」、「Font Inflation」,是 Webkit 給移動端瀏覽器提供的一個特性:當我們在手機上瀏覽網頁時,很可能因為原始頁面寬度較大,在手機屏幕上縮小后就看不清其中的文字了。而 Font Boosting 特性在這時會自動將其中的文字字體變大,保證在即不需要左右滑動屏幕,也不需要雙擊放大屏幕內容的前提下,也可以讓人們方便的閱讀頁面中的文本。
不過這個特性並不總是有必要的,還好在查到問題原因的同時,大家也討論了對這個問題的一些處理方案:
- 手動指定
viewport width=320
,這時 Font Boosting 不會被觸發。(后邊可以知道,這個說法不嚴謹,在其他設置均為默認值時,這一條才有效) - Font Boosting 僅在未限定尺寸的文本流中有效,給元素指定寬高,就可以避免 Font Boosting 被觸發。
- 顯然第 2 條方案是有缺陷的,文本內容不可能都指定寬高。不過還好,我們通過指定
max-height
,(經 @Ovaldi 指正,只有min-height
,min-width
,max-width
max-height
有效) 也是可以的。比如body * { max-height: 999999px; }
就可以無副作用的禁掉 Font Boosting 特性。當然,我覺得沒必要使用通用選擇器,用類似p { max-height: 999999px; }
可能更好一些。
到這里,我們已經明白問題所在,並且也有解決方案了。但是有一個問題仍然困擾着我:當字體大於某一個值時(比如當不指定viewport width,手機屏幕width=320,字體大於等於82px時),這個 Font Boosting 就始終不會被觸發。Chrome 是如何計算的,這其中的邏輯又是什么?
這一次問題解決起來就沒有那么容易了,我先是各種搜索無果,然后自己人肉去試,慢慢找規律,但是發現變化不是線性的,看來這個公式還比較復雜。終於在今天被我發現了這篇文章:Chromium's Text Autosizer,徹底解釋了我的疑問。
Font Boosting 具體的實現代碼在 TextAutosizer.cpp 這個文件中可以看到,有興趣的可以翻一下。
簡單說來,Font Boosting 的計算規則偽代碼如下:
multiplier = Math.max(1, deviceScaleAdjustment * textScalingSlider * systemFontScale * clusterWidth / screenWidth); if (originFontSize < 16) { computedFontSize = originFontSize * multiplier; } else if (16 <= originFontSize <= (32 * multiplier - 16)) { computedFontSize = (originFontSize / 2) + (16 * multiplier - 8); } else if (originFontSize > (32 * multiplier - 16)) { computedFontSize = originFontSize; }
其中變量名解釋如下,更具體的說明可以參考上邊的兩個鏈接。
originFontSize
: 原始字體大小computedFontSize
: 經過計算后的字體大小multiplier
: 換算系數,值由以下幾個值計算得到deviceScaleAdjustment
: 當指定viewport width=device-width
時此值為 1,否則值在 1.05 - 1.3 之間,有專門的計算規則textScalingSlider
: 瀏覽器中手動指定的縮放比例,默認為 1systemFontScale
: 系統字體大小,Android設備可以在「設備 - 顯示 - 字體大小」處設置,默認為 1clusterWidth
: 應用 Font Boosting 特性字體所在元素的寬度(如何確定這個元素請參考上邊兩個鏈接)screenWidth
: 設備屏幕分辨率(DIPs, Density-Independent Pixels),如 iPhone 5 為 320
說了這么多,貌似只需要記住
指定的元素{ max-height: 999999px; }
用 max-height: 100%
可能會更好一些。