CSS藏了3年的1行代碼，讓設(shè)計師集體破防

2023年，Chrome 114版本悄悄上線了一個屬性。沒人開發(fā)布會，沒上熱搜，但前端圈后來叫它"排版救星"——text-wrap: balance。這行代碼解決了一個折磨網(wǎng)頁設(shè)計20年的老毛病：標(biāo)題斷行丑得像車禍現(xiàn)場。

問題有多普遍？打開任意新聞網(wǎng)站，找三行以上的大標(biāo)題，大概率最后一行只剩1-2個詞孤零零掛著。設(shè)計師管這叫"寡婦行"（widow），讀者叫"丑"，老板叫"不專業(yè)"。

一行代碼，瀏覽器幫你算排版

傳統(tǒng)做法是設(shè)計師手動插
標(biāo)簽，或者寫死每行字?jǐn)?shù)。但響應(yīng)式布局時代，屏幕寬度千變?nèi)f化，人工斷行根本追不上。text-wrap: balance的思路很直白：瀏覽器在渲染前，先算一遍怎么分詞能讓各行長度最均勻。

Shivam Pawar在Medium的測試案例很典型。一個三行標(biāo)題，默認(rèn)渲染第三行只剩"Fix"一個詞；加上這行CSS，變成"for Ugly"和"Headings"各占一行，視覺重量立刻平衡。不是近似平衡，是算法意義上的最優(yōu)解。

實現(xiàn)方式簡單到離譜：

h1, h2, h3 {
text-wrap: balance;
}

就這三行。不需要JS，不需要算容器寬度，不需要監(jiān)聽resize事件。瀏覽器自己在排版引擎里完成了以前要靠復(fù)雜腳本才能實現(xiàn)的效果。

為什么現(xiàn)在才有人用

兼容性曾經(jīng)是攔路虎。2023年Chrome 114首發(fā)時，F(xiàn)irefox和Safari還沒跟上。到2024年初，F(xiàn)irefox 121才加入支持；Safari則是2024年3月的17.4版本。換句話說，這屬性真正"能用"還不到兩年。

但Pawar的數(shù)據(jù)點值得關(guān)注：現(xiàn)代瀏覽器覆蓋率已經(jīng)超過92%。剩下的8%主要是企業(yè)內(nèi)網(wǎng)的老IE和鎖死版本的安卓WebView，對C端產(chǎn)品幾乎可以忽略。

漸進增強（progressive enhancement）策略在這里很安全。老瀏覽器看到不認(rèn)識的屬性直接忽略，標(biāo)題回落到傳統(tǒng)斷行——雖然丑，但不崩。新瀏覽器用戶獲得優(yōu)化體驗，兩邊各取所需。

別濫用，它只適合"重要文本"

瀏覽器做這個平衡計算是有成本的。Pawar明確提醒：別給整篇文章開這個，只給標(biāo)題（h1-h3）用。長文本用balance會讓瀏覽器在渲染前遍歷太多斷行可能，反而拖慢頁面。

另一個隱藏限制：這屬性只對不超過6行的文本生效。超過6行，算法復(fù)雜度暴漲，瀏覽器會自動切回普通換行。這個閾值是硬編碼在Chromium源碼里的，沒暴露給開發(fā)者調(diào)。

實際項目中，配合text-wrap: pretty（處理孤行）和hyphens: auto（自動斷詞）能組成一套現(xiàn)代排版方案。但balance是核心——它解決的是"視覺重心"問題，不是技術(shù)問題。

從"手動調(diào)"到"算法自動"

這個屬性的背后趨勢更值得玩味。CSS正在從"描述樣式"進化成"委托決策"——開發(fā)者不再指定每一像素怎么擺，而是定義目標(biāo)（"要平衡"），讓瀏覽器自己找最優(yōu)解。

容器查詢（container queries）、clamp()函數(shù)、子網(wǎng)格（subgrid），都是同一脈絡(luò)。前端工程師的角色在微妙轉(zhuǎn)移：從"實現(xiàn)細節(jié)"轉(zhuǎn)向"定義約束"。

Pawar在文末拋了個問題：用了text-wrap: balance之后，你還會手動插
嗎？

我的觀察是：設(shè)計團隊內(nèi)部正在分化。年輕設(shè)計師直接全量采用，老派設(shè)計師還在質(zhì)疑"瀏覽器算的不一定比我審美準(zhǔn)"。但A/B測試數(shù)據(jù)很誠實——平衡標(biāo)題的平均閱讀完成率高出4-7%，這個差距足夠讓產(chǎn)品拍板。

你的項目里，標(biāo)題斷行現(xiàn)在是人工控還是交給算法？最近一次因為"最后一行字?jǐn)?shù)太少"被設(shè)計評審打回，是什么時候？