為什麼 HTML+CSS 架構在跨語言 typography 方面總是達不到 Microsoft Word 的水平（兩種技術有何不可比之處）？

01-02

中英文之間自動加空白（不是空格）、中文標點符號減空白（不是空格）、靈活而正確的兩端對齊……為什麼寫網頁的時候無法享受這些？不可能是因為「以前不知道」吧，因為Word早就在那裡了。
是跟計算機內存或者屏幕解析度之類的硬體發展歷史局限性有關嗎？
還是由於諸如「飽暖思淫慾」這樣的「需求等級理論」，一開始連最基本的問題都解決不了所以明知不好也先不解決這種「美觀」層面上的問題？

為什麼到現在看網頁我還要忍受失敗的text-align: justify;？

另外一位答題者 @bombless 說「HTML 原本就是用於表達結構化的文檔而已，並不是一個排版工具」，對，沒錯，當然—— CSS 才是用來排版的。HTML+CSS 架構適合排版，CSS 就是用來給 HTML 內容排版的。

@bombless 還說「題主的這個需求在前端工程師的角度來看叫做「過度表現」」——不，這不是過度表現，這也不是前端工程師的職責範疇。這只是 CSS 還未實現的基礎需求而已。等再過十年，這些特性默認開啟，就不會有前端工程師認為它們是過度表現了——反正前端工程師們一直既不懂也不關心這方面。

* * *

@余天升提到可以用各種方法為 HTML 加上標記然後實現中西文間距、標點擠壓、兩端對齊這類事情——這和這個問題無關。這些排版細節本身就是與內容無直接聯繫的樣式，不應當用 HTML 標籤來輔助。各種 hacking 方式誰都知道，但問題在於這些應當由 CSS 完成，而且相關規範已經在制訂中。

從網頁代碼到網頁渲染結果，中間階段是排版引擎在處理；而 Word 只是把排版引擎的一部分工作結果寫入了文件，讓渲染更簡單，那是個處理過程的中間產物。不應當把 Word 的文件中存儲的那些中間信息當作同 HTML+CSS 這種原始內容和指令等同的東西。

* * *

HTML+CSS 的排版能力不僅達不到 Microsoft Word 的水平，也達不到 Adobe InDesign 的水平，也達不到 TeX 的水平。

但 HTML+CSS 已經達到或超過了各桌面、移動操作系統 API 提供的排版能力。

Word、InDesign、TeX、DOC(X)、PDF……這些東西都是為印刷和出版而生的。印刷和出版對排版細節的要求高，工作流程封閉且線性，用一個公司/社區的產品就能搞定輸入和輸出。

HTML+CSS 服務的是去中心化的萬維網。一個 author 製作的網頁會在無數用戶五花八門的 UA 里渲染，不可控；內容動態，多變，需要處理的問題就更複雜。

而操作系統介面要解決的情況更單純，能力也更不全面。

設計師們遇到一些腦殘印刷作坊要求提供 InDesign 原文件然後作坊的 InDesign 版本過低又打不開就已經很抓狂了，必須依賴 PDF 才能省心。可 web 開發者每天面對的是從 IE6 到 Chrome 21 的瀏覽器，字體不定、操作系統 API 不定、排版引擎不定。

如果像 web 開發者面對眾多瀏覽器一樣，讓平面設計師天天都做必須和 Word、Pages、http://OpenOffice.org、InDesign、QuarkXPress、CorelDRAW……能共享的設計，還有多少排版特性能順利實現？InDesign 直到 CS6 才正式支持印度系文字的排版，但沒法在一個段落內同時處理印度系文字和 CJK 的排版需求，並不比 HTML+CSS 強多少。

如今 WebKit、Gecko 和 Trident 三分天下，各自版本眾多，Google、Apple、Mozilla、微軟……各個開發團隊/社區有自己的開發重心。讓多方參與並認同 W3C 的決策就已經很不容易，完全沒法指望他們能用多高的效率去實現 CSS 那麼多細緻的特性。

對排版引擎來說，CSS3 靈活的 layout 特性、性能優化、HTML5 的多媒體特性……那麼多重要工作需要做，能有多少精力放在「讓網頁像出版物一樣精美」上？CJK 社區的需求再怎麼強烈也不如全人類共享的特性重要——何況 CJK 社區其實沒有多少聲音發出來。

有的開發社區一直相對注重這些事情，比如 WebKit。WebKit 在 OS X 上早就實現了和 Windows 里 IE、Firefox 一樣的 text-align: justify，不知道為何 WebKit 在 Windows 上沒有實現這點。

你明明是有選擇的：在 Windows 上用 IE 或 Firefox，在 OS X 上用 Safari、Chrome 或 Firefox。你根本就不用忍受「失敗的 text-align: justify」。甚至，如果你這麼在乎排版細節，你根本就不應當用 Windows。

可你還是很糾結，大概因為你指望天下所有的瀏覽器都支持你在乎的特性。

這不可能。

互聯網的魅力就在於它扁平、開放、百家爭鳴、風起雲湧。用 InDesign 這 Adobe 一家的產品時都會遇到令人無奈的版本問題，何況千變萬化的互聯網。Web 設計和前端開發共同面對的最大挑戰和最大價值之一就是彈性，這是不可擺脫的。盡量利用新特性，讓 Windows 里的 IE、Firefox 用戶以及所有 Mac 用戶都能享受到良好的 text-align: justify，而其他用戶不受負面影響，這還不夠好嗎？

* * *

另可參見 @霏昀在另一個答案中的觀點： http://www.zhihu.com/question/20443036/answer/15166968

本答案略長，主要是討論問題，看結論請直接跳至最後一句。

我認為，HTML+CSS 是可以達到接近 Word 一樣的排版效果的。比如題主提到的中西文之間的空白，是完全可以實現的。（本人不會做前端，代碼寫得不好勿噴）

上圖是一個實現中西文之間間距的一個demo。不過看起來實現方法很複雜，需要為每一段文字單獨做一個標記，然後用 CSS 來控制間距。

Word 中這些都是自動的，為什麼在 HTML 裡面要那麼麻煩呢？Word 2007 以後版本的文檔，都是開放格式的，把擴展名 docx 改成 zip，然後用任意一款壓縮軟體解壓就可以看到裡面的內容：Word 通過一堆 XML 描述文檔的內容和布局，當然包括這個間距。然後我打開了解壓後 word 目錄下的document.xml 文件，這個是 Word 裡面對於這個文本的描述（調整過 XML 結構以便閱讀）。

很湊巧，Word自動地按照不同的語言，把這段文字拆解成了一段一段的。而且實驗表明，Word 是會檢查這些分段的，也就是說，如果我修改這個 XML，將「佛陀綉譜」和「就是」分開成兩個部分，然後保存重新變回 docx，用 Word 打開之後這兩個詞之間是沒有間距的。重新保存一次，又會恢復成上圖的那個樣子。

另外一個實驗，使用 Word 自帶的另存為功能，保存為 HTML 格式，提示了一個會有部分格式丟失。打開這個 HTML，中英文之間的間距確實沒有了，不過，文字還是按照上面的方式，放在了不同的 span 中。所以我相信，這些文字在 Word 的內存中是被區別對待的。

打開那些 XML 粗略看了一下，Word 中用來表述樣式屬性的 XML，感覺和 CSS 差距並不大，也都是一些邊距、位置、顏色等等之類的東西，所以要想用 CSS 達到相似的結果，那麼使用的代碼量也應當相當才對，而僅僅通過增加一個屬性來達到，似乎太天真了。

據此，我認為，之所以我們在 HTML 中沒有辦法達到 Word 那樣的效果，是因為我們對於文檔的標記不夠複雜。Word 使用的 XML 標記和屬性就很複雜，下圖是那個 docx 解壓以後的文件，包含了一個 16KB 的 styles.xml。

因此我覺得 @梁海所說的「HTML+CSS 的排版能力不僅達不到 Microsoft Word 的水平，也達不到……」不完全正確。我不做前端不敢妄下「HTML+CSS一定能達到或者超過Word水平」的結論，但至少也不會差距特別大吧，至少，在使用相同複雜的標記和 CSS 的情況下，是可以的。@梁海所說的，我覺得表述為「從設計師角度，HTML+CSS 的排版能力不能簡便地達到 Microsoft Word 的水平，也……」更為合適。Word 幫我們完成了太多太多的我們沒有注意到的工作，而在 HTML+CSS 中沒有辦法以相同的工作量達到這樣的效果，所以被誤解為不能。CSS 應該是一個基礎的、描述布局的語法，如果 Word 中的那些 XML，不能像 Word 中的操作那樣輕易的完成各種各樣複雜的排版工作。

不過，設計師，哪裡知道那麼多這些實現的細節，他們想做的只是製造出他想要的樣子。我承認我是從工程師的角度理解這個問題了。

在工程師看來，可能還有很多東西不太好做，比如（我承認我在瞎舉例）中英文之間有間距，如果我增加了一個叫做「中英文間距」的 CSS 屬性，過些日子又有了關於中文和法文混排的例子了怎麼辦。有時候，遇到一些跟語義相關的問題，計算機可能也無法很好的解決了，比如這個問題提到的，http://www.zhihu.com/question/20403239 。

結論是，我認為 HTML+CSS 可以達到 Word 一樣的效果，不過要麻煩一些，但是這些麻煩在 Word 中 Word 已經自己幫你做了，而在 HTML 中我們只能自己做。

從軟體開發的角度。

一個設計要從幾個方面考慮：

需要解決的首要問題
目標運行環境，包括軟體和硬體
功能實現的代價和收益的衡量

HTML 是在互聯網上傳遞富文本（相對text 文件）的規範格式，並且希望能夠在不同平台下能夠得到相對一致的顯示效果。

早期互聯網更多的考慮有效數據傳輸量。而越多的格式就越需要越多的格式配置信息，比如：一個普通網頁最多幾十K就夠了，而一頁word文檔可能要幾百K。

HTML是呈現在電腦屏幕上的，由於有一定的可交互特性（點擊鏈接查看另一頁）和可變動位置（通過滾動條上下移動）查看，不必拘泥於將所有內容全部在一個按照紙面的固定尺寸(比如A4,A5等）內顯示，即對排版的需求沒那麼高。

因此，早期的HTML規範的設計就沒有引入很多的格式和排版能力。

為了實現 HTML跨平台性，HTML的顯示是由瀏覽器完成的，而不同平台的瀏覽器，受操作系統的限制，能處理的標籤也是受限的。甚至同一平台下，不同廠商的瀏覽器的顯示效果也可能不一樣。

而後來，為了減少 HTML文件在不同瀏覽器間發生顯示不一致的情況，成立的規範制定委員會，而新的格式標記，往往要經過好多討論才能確定下來。

這樣，HTML支持的格式相對於 Word這種可以自行定義格式規範的文字處理系統，增長速度慢了很多。同時，為了跨平台性，兼容性，也放棄了很多特性的支持。

嗯，早期HTML的設計沒有設計師參與可能也是問題

光從排版和顯示效果來說，HTML+CSS可以達到Word的水平。

問題是編輯，對頁面元素進行操作需要大量的函數介面，而HTML的DOM和Range，提供的介面不可能那麼豐富。

網頁渲染引擎，肯定要有所取捨，如果方方面面都照顧到了，瀏覽器就會變得臃腫無比。

術業有專攻，瀏覽器和Word各自所要解決的事情不一樣，決定了HTML本身不會和Word文檔一樣，也沒必要。

一套 font 就能搞定 , 在 font 里內置字元檢測功能 , 將每個字元的載入作為觸發事件就 OK , 這是在 node.js 這種神器的處理範圍之內的 .

當然 , 此時瀏覽一張網頁所佔的內存 , 基本就相當於一個圖文並茂的 Word 文檔打卡之後所佔用的內存 , 這就是代價 .

為什麼你能夠同時瀏覽二三十個所謂的「失敗到連對齊都不做好」的網頁而電腦不卡 , 但同時打開十個 word 文檔等這些所謂的「為了出版和印刷而生」的文本格式電腦就會很卡 ?

並不是不可以，只不過代價比較大。

你可以去看一下豆瓣閱讀器在線版的排版方式，是用絕對坐標控制每一個字元的位置的，效果還湊合。

如果不是一群SB為個盒子模式爭了10年，現在這些應該早就實現了。