HTML 一直是我們編譯的目標 – 我們可以解決好它嗎？
每隔幾周，Web 開發者的 Twitter 圈都會因為糟糕的 HTML 程式碼而吵到瘋狂。但 HTML 只是一些帶有各種各樣屬性的 div 和 span 而已。有些 HTML 不僅缺乏任何可見的介面，例如錨點或按鈕，也缺乏任何結構，例如頭部和列表。啊，這就是非語義的 HTML，不可讀的 HTML。
HTML 的定義很清晰，由於它的語法有著很高的容錯率，它也很健壯。在XHTML時代，我們試圖讓HTML降低容錯率，但是網路環境不允許我們這樣做。開發者犯下的錯不應讓使用者背鍋，而應該讓瀏覽器寬容 HTML 同時在渲染時自動修復錯誤。這個問題應讓我們產生擔憂：我們被迫忍受多年來瀏覽器的糟糕決定。這就是為什麼 HTML 不像其它語言那樣（進步得很快）—— 因為瀏覽器太臃腫和緩慢了。
HTML 允許我們犯錯
首先，HTML 的高容錯率幫助了 web 世界存活下來。它確保了現代瀏覽器也可以顯示很老的內容，而無需進行更改。很多年的 Flash 內容現在都無法使用了，這件事證明在網路這樣波動很大的環境中，容錯率高是一件正確的事情。
但是, 這確實意味著對非語義 HTML 沒有可感知到的錯誤。用 div、span 來實現 table 佈局仍然可以正常工作（說的就是這個網站：hackernews）
展示給我們所有內容的瀏覽器讓我們感到擔心，因為它讓“乾淨整潔“和“語義化”的 HTML 變成了一種少數人擁有的特殊技能。HTML 作為網路創作的文字，其書法千千萬，其中有大多數的內容都像是隨意塗寫的塗鴉。
語義化的 HTML 是很棒的，我們可以確保它沒有問題。你可以從語義化的 HTML 中得到很多顯而易見的好處。它往往表現得更好，它通常也意味著沒有第三方依賴，也容易閱讀和理解。我們中的很多人學習 web 知識是通過閱讀其他 web 站點的原始碼，這個方法已經過時了，我幾個月前寫了這篇文章。
現在是時候開始在更成熟的層面上處理這個問題，而不是每隔幾個月就重複同樣的抱怨了。
HTML 一直都是一個編譯目標。“手寫 HTML” 的玩法僅僅適用於一小部分吵鬧的愛好者。
我是那些吵鬧的愛好者中的一員，至今我已經寫了 14 年部落格了。我熱愛這個對所有人都開放的 web 世界。你只需要一個編輯器，一些（工具的）使用文件就可以在 web 世界上釋出你的作品。
手寫的 HTML 是稀有品，它應該是收藏品
大約20年前，當我開始成為一名 web 開發者的時候，（用工具編譯 HTML）並不是人們的工作方式。那個時候沒有什麼特別大的 web 產品被創造出來——事實上，一個職位需求中沒有要求“手寫 HTML/CSS/JS 的能力“都是很反常的。那時關注 HTML 規範化的是一個精英匯聚、興趣濃厚的團體。如果你可以讓 web 世界變得更加清晰，更加語義化，那麼你就是一個很棒的人。但是我們到底要改變什麼呢？
web 世界的大部分都是基於除了 HTML 以外的其他技術：
- 服務端基礎（記得 .shtml 頁面嗎）
- CGI/Perl 模版引擎
- 用內容管理系統和我們自定義的模版語言來生成 HTML
- 用來生成一些類似於 HTML 的 WYSIWYG（所見即所得）編輯器
- 模版語言，例如 PHP、ColdFusion、Template Toolkit、ASP 以及其它
- 線上編輯器和頁面生成器，例如 Geocities
- 論壇和部落格編輯器有時擁有自己的語言（還記得 BBCode 嗎？）（譯者注：BBCode 是一類標記語言，類似於 Markdown。wiki：zh.wikipedia.org/wiki/BBCode…
這些技術沒有一件是在 web 上釋出產品所必需的。但在我工作過的一些大型公司中，他們的內容管理系統是及其複雜和龐大的，但人們卻選擇用它。因為它提供了一個更簡單、更明確、更清晰的 web 內容釋出途徑。他們解決的是開發人員和產品經理之間的問題, 而不是終端使用者體驗。Geocities 及類似的服務讓人們在網路上釋出作品更加容易，因為這些服務使得人們甚至不需要編寫任何程式碼。
你在瀏覽器裡看到的幾乎不會是原始碼。如果你想去提高程式碼質量，你需要去追溯到程式碼的源頭。
即使我們選擇看網頁的原始碼，那也不是某個人寫的程式碼，而是由服務端程式碼處理各種資料甚至是優化後返回給瀏覽器的程式碼。
這樣做是有其道理的。有很多不同的公共元件允許人們同時使用它們。一般情況下，你的網站導航是全球性的，甚至是由其他部門或公司編寫和維護的。你甚至無法修改 HTML，如果幸運的話，你可以解決網站 CSS 的一些問題。
HTML 是一個編譯目標
我們回到現在。HTML 並不是一個很酷的東西，各類模版語言（例如 Markdown Pug、Jade 以及其它）層出不窮。這些模版語言都希望能讓我們從 HTML 在不同環境下的可靠性和相容性問題中解脫出來。
HTML 有一個在某處可用，卻不能確保其它地方可用的壞名聲。比起只能確保相容老舊技術的框架，一個能提供更強功能且與時俱進的框架會更加令人興奮。
web 世界不應該受到我們的控制，但是我們需要去滿足使用者的需求。對於他們來說，在規定時間內給出了被需求的介面才是他們的任務。我們應該改變這個現狀！
HTML 看起來不是我們所需要擔心的東西——它在一個容錯率高的環境中執行。它通常被看作是更好地利用你的時間來學習更高的抽象。人們不希望建立一個單純意義上的網站，而是想構建一個應用程式。儘管大多數情況下，他們並不需要一個應用。我們在保證 HTML 的趣味性上犯錯誤了。我們希望網路能給我們更多的功能，讓其可以與手機上的原生程式碼並駕齊驅。但這總是導致我們的應用有更高的複雜度。構建可擴充套件 web 的宣言 基本證明了網路上的釋出者需要有比實體的作家或出版商更多的開發者思維。我們想要控制，我們想要負責。現在我們是這樣做了。
這樣做讓我們剩下了什麼？首先，我們需要去相容現在 web 世界中現有的由伺服器處理過的程式碼。檢視最終結果、感嘆其程式碼質量是沒有意義的。沒有人寫過這些程式碼，意味著它是不可讀的。
我不會放棄語義化 HTML 及其優點，但我明白，我們不會通過告訴開發者他們的產品是可怕的來說服他們。我們需要與框架開發人員合作，這些開發人員是元件的建立者。我們需要幫助模板原始碼，這些模板原始碼是框架渲染器。我們需要確保轉換階段產生良好的 HTML 程式碼——而不是簡單的 HTML。
同時我們需要和工具開發者合作來確保人們瞭解語義化的價值。整合在編輯器內的程式碼 Lint 和自動化有很大的發展潛力。現在我們有了更多的工具可供選擇，以確保開發人員做正確的事情，而不必考慮它。我喜歡這個主意，它讓我們從源頭上解決問題，而不是抱怨症狀。
如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。