大約 15 年前，我在一家公司工作，我們為旅行社、機場工作人員和航空公司開發應用程式。我們也為 UI 元件和單頁應用程式功能建立了自己的內部框架。 我們擁有適用於所有內容的元件：欄位、按鈕、標籤、範圍、資料表、選單、日期選擇器、選擇和多選。我們甚至還有一個 div 組件。順便說一句，我們的 div 元件非常棒，它允許我們在所有瀏覽器上實現圓角，無論你相信與否，這在當時並不是一件容易的事情。
我們的工作發生在我們歷史上的某個時刻，當時 JS、Ajax 和動態 HTML 被視為一場帶我們走向未來的革命。突然間，我們可以動態更新頁面，從伺服器獲取數據，並避免導航到其他頁面，這被認為是緩慢的，並且在兩個頁面之間的螢幕上閃爍一個大的白色矩形。 傑夫·阿特伍德（Jeff Atwood，StackOverflow 創始人）流行了這樣一句話： 「任何可以用 JavaScript 編寫的應用程式最終都會用 JavaScript 編寫。」—— Jeff Atwood
對於當時的我們來說，這感覺像是真正敢於創建這些應用程式。感覺就像是對 JS 所做的一切都給予了全面認可。 所以我們所有的事情都用 JS 來做，我們並沒有真正花時間去研究其他的做事方式。我們並沒有真正感受到正確學習 HTML 和 CSS 功能的動力。我們並沒有真正將網路視為一個完整的不斷發展的應用程式平台。我們大多認為這是我們需要解決的問題，特別是在瀏覽器支援方面。我們可以投入更多的 JS 來完成任務。 花時間進一步了解網路的運作方式以及平台上的可用內容會對我有幫助嗎？當然，我可能會刪掉一堆其實不需要的程式碼。但在當時，也許沒有那麼多。 你看，當時瀏覽器的差異非常顯著。當時，Internet Explorer 仍然是主導的瀏覽器，Firefox 緊隨其後，但由於 Chrome 的迅速普及而開始失去市場份額。儘管Chrome和Firefox在網路標準上達成了一致，但我們的應用程式運行環境意味著我們必須長期支援IE6。即使我們被允許支援 IE8，我們仍然必須處理瀏覽器之間的許多差異。不僅如此，當時的網路還沒有在平台內建那麼多多功能。
快進到今天。事情發生了巨大的變化。我們不僅擁有比以往更多的這些功能，而且它們可用的速度也有所增加。 那麼，讓我再問一次這個問題：今天花時間了解更多有關網絡如何運作以及平台上提供的內容對您有幫助嗎？絕對是的。今天學習理解和使用網路平台將使您比其他開發人員具有巨大的優勢。 無論您是致力於效能、可訪問性、響應能力，還是所有這些一起工作，或者只是交付 UI 功能，如果您想作為負責任的工程師來做到這一點，那麼了解可用的工具可以幫助您更快更好地實現目標。 有些事情你可能不再需要圖書館了 在了解了當今瀏覽器支援的內容後，問題是：我們可以放棄什麼？ 2025 年我們還需要一個 div 元件來做圓角嗎？當然，我們不這麼做。目前所有目前使用的瀏覽器都支援 border-radius 屬性超過 15 年。轉角形狀也即將推出，適用於更精美的轉角。 讓我們來看看現在所有主要瀏覽器中都可用的相對較新的功能，您可以使用它們來替換程式碼庫中的現有依賴項。 重點不是立即拋棄所有你喜愛的函式庫並重寫你的程式碼庫。至於其他一切，您需要先考慮瀏覽器支援，並根據專案特定的其他因素做出決定。以下功能在三個主要瀏覽器引擎（Chromium、WebKit 和 Gecko）中實現，但您可能有不同的瀏覽器支援要求，導致您無法立即使用它們。不過，現在仍然是了解這些功能並可能計劃在某個時候使用它們的好時機。 彈出視窗和對話框 Popover API、
當然，您的網路連線速度可能也有所提高，但並非每個人都是如此。而且並非每個人都有相同的設備功能。 相反，為您可以使用該平台執行的操作引入第三方程式碼，很可能意味著您發布了更多程式碼，因此接觸到的客戶比平常少。在網路上，糟糕的載入效能會導致很高的放棄率並損害品牌聲譽。 在設備上運行更少的程式碼 此外，如果您在客戶裝置上發布的程式碼在平台上使用較少的 JavaScript 抽象，則可能會運行得更快。預設情況下，它也可能響應更快、更易於訪問。所有這些都會帶來更多、更滿意的客戶。 查看我的同事 Alex Russell 的年度性能不平等差距博客，該博客顯示，由於財富不平等，擁有數十億用戶的市場基本上缺乏高端設備。而且隨著時間的推移，這種差距只會越來越大。
內置砌體佈局 CSS Masonry 是即將推出的一項令我非常興奮的 Web 平台功能。
讓我先解釋一下什麼是 Masonry。 什麼是砌體 Masonry 是幾年前 Pinterest 流行的一種佈局類型。它創建獨立的內容軌道，其中的項目盡可能靠近軌道的開頭進行打包。
許多人認為 Masonry 是作品集和照片畫廊的絕佳選擇，它確實可以做到這一點。但 Masonry 比你在 Pinterest 上看到的更靈活，而且它不僅限於瀑布式佈局。 在砌體佈局中：
軌道可以是列或行：
內容軌道不必全部具有相同的大小：
專案可以跨越多個軌道：
物品可以放置在特定的軌道上；他們不必總是遵循自動放置演算法：
示範 以下是我使用即將在 Chromium 中實現的 CSS Masonry 製作的一些簡單示範。 照片庫演示，展示項目（本例中的標題）如何跨越多個軌道：
另一個展示不同尺寸軌道的照片庫：
新聞網站佈局，其中一些軌道比其他軌道更寬，並且一些項目跨越佈局的整個寬度：
看板顯示可以將項目放置到特定軌道上：
註：先前的示範是使用 Chromium 版本製作的，大多數 Web 使用者尚未使用該版本，因為 CSS Masonry 才剛開始在瀏覽器中實作。 然而，Web 開發人員多年來一直很樂意使用函式庫來建立 Masonry 佈局。 當今使用砌體的網站 事實上，Masonry 在當今的網路上非常常見。以下是我在 Pinterest 之外找到的一些例子：
還有一些不太明顯的例子：
那麼，這些佈局是如何創建的呢？ 解決方法 我見過的一個技巧是使用 Flexbox 佈局，將其方向更改為列，並將其設定為換行。 這樣，您可以將不同高度的項目放置在多個獨立的列中，給人以砌體佈局的印象：
但是，此解決方法有兩個限制：
項目的順序與真正的砌體佈局不同。使用 Flexbox，項目首先填入第一列，當填滿時，然後轉到下一列。使用 Masonry，物品將堆疊在有更多可用空間的軌道（或本例中的列）中。 而且，也許更重要的是，此解決方法要求您為 Flexbox 容器設定固定高度；否則，不會發生纏繞。
第三人 Masonry 庫 對於更高級的情況，開發人員一直在使用庫。 最知名、最受歡迎的函式庫是 Masonry，根據 NPM 的數據，它每週的下載量約為 20 萬次。 Squarespace 還提供了一個佈局元件，可以呈現 Masonry 佈局，作為無程式碼替代方案，許多網站都使用它。 這兩個選項都使用 JavaScript 程式碼將專案放置在佈局中。 內置砌體 我真的很高興 Masonry 現在開始作為內建 CSS 功能出現在瀏覽器中。隨著時間的推移，您將能夠像使用 Grid 或 Flexbox 一樣使用 Masonry，即不需要任何解決方法或第三方程式碼。 我在 Microsoft 的團隊一直在 Chromium 開源專案中實現內建 Masonry 支持，Edge、Chrome 和許多其他瀏覽器都基於該專案。 Mozilla 實際上是第一個在 2020 年提出實驗性實作 Masonry 的瀏覽器供應商。 Apple 也對實現這種新的 Web 佈局原語非常感興趣。 標準化此功能的工作也在取得進展，CSS 工作小組內部就總體方向，甚至新的顯示類型顯示：網格通道達成了一致。 如果您想了解更多有關 Masonry 的資訊並追蹤進度，請查看我的 CSS Masonry 資源頁面。 隨著時間的推移，當 Masonry 成為 Baseline 功能時，就像 Grid 或 Flexbox 一樣，我們將能夠簡單地使用它並受益於：
更好的性能， 更好的反應能力， 易於使用和更簡單的程式碼。
讓我們仔細看看這些。 更好的性能 製作自己的類似 Masonry 的佈局系統，或使用第三方函式庫，表示您必須執行 JavaScript 程式碼才能將專案放置在螢幕上。這也意味著這段程式碼將被渲染阻塞。事實上，在 JavaScript 程式碼運行之前，要嘛什麼也不會出現，要嘛東西不會位於正確的位置或大小不正確。 砌體佈局通常用於網頁的主要部分，這意味著程式碼將使您的主要內容比原本可以出現的時間晚，從而降低您的 LCP（即最大內容繪製指標），該指標在感知效能和搜尋引擎優化中發揮著重要作用。 我使用簡單的佈局並透過在 DevTools 中模擬慢速 4G 連接來測試 Masonry JS 庫。該庫不是很大（24KB，gzip 後為 7.8KB），但在我的測試條件下加載需要 600 毫秒。 下面是一個效能記錄，顯示 Masonry 庫的載入時間長達 600 毫秒，並且在此期間沒有發生其他渲染活動：
此外，在初始載入時間之後，需要對下載的腳本進行解析、編譯，然後執行。正如前面提到的，所有這些都會阻止頁面的渲染。 透過瀏覽器中內建的 Masonry 實現，我們將不需要載入和運行腳本。瀏覽器引擎只會在初始頁面渲染步驟中執行其操作。 更好的響應能力 與首次載入頁面時類似，調整瀏覽器視窗大小會導致再次渲染該頁面中的佈局。不過，此時，如果頁面正在使用 Masonry JS 庫，則無需再次載入腳本，因為它已經這裡。但是，需要執行將項目移至正確位置的程式碼。 現在，這個特定的庫在頁面加載時似乎可以非常快地執行此操作。然而，當項目需要在視窗調整大小時移動到不同位置時，它會為項目設定動畫，這會產生很大的差異。 當然，使用者不會像我們開發人員一樣花時間調整瀏覽器視窗的大小。但這種動畫調整大小的體驗可能會非常不和諧，並且會增加頁面適應新尺寸所需的時間。 易於使用且程式碼更簡單 使用 Web 功能的容易程度以及程式碼看起來的簡單程度是可以為您的團隊帶來巨大變化的重要因素。當然，它們永遠不會像最終用戶體驗那麼重要，但開發人員體驗會影響可維護性。使用內建網路功能在這方面具有重要的好處：
已經了解 HTML、CSS 和 JS 的開發人員很可能能夠輕鬆使用該功能，因為它的設計目的是與 Web 平台的其他部分很好地整合並保持一致。 此功能的使用方式並無重大變化的風險。 該功能被棄用或不再維護的風險幾乎為零。
對於內建 Masonry，因為它是一個佈局基元，所以您可以從 CSS 中使用它，就像 Grid 或 Flexbox 一樣，不涉及 JS。此外，其他與佈局相關的 CSS 屬性（例如間隙）也可以按照您的預期工作。沒有任何需要了解的技巧或解決方法，您學到的東西都記錄在 MDN 上。 對於 Masonry JS 函式庫，初始化有點複雜：它需要具有特定語法的資料屬性，以及隱藏的 HTML 元素來設定列和間隙大小。 另外，如果您想跨越列，您需要自行包含間隙大小以避免問題：
<風格> .軌道大小調整器， .項目{ 寬度：20%； } .gutter-sizer { 寬度：1rem； } .項目{ 高度：100px； 邊距區塊結束：1rem； } .item:nth-child(奇數) { 高度：200px； } .item--width2 { 寬度：計算（40% + 1rem）； }
讓我們將其與內建 Masonry 實作進行比較： <風格> .容器{ 顯示：網格車道； 網格車道：重複(4, 20%)； 間隙：1rem； } .項目{ 高度：100px； } .item:nth-child(奇數) { 高度：200px； } .item--width2 { 網格列：跨度 2； }
更簡單、更緊湊的程式碼，可以只使用間隙之類的東西，其中跨越軌道是用跨度 2 完成的，就像在網格中一樣，並且不需要您計算包括間隙大小的正確寬度。 如何知道哪些內容可用以及何時可用？ 總的來說，問題不在於是否應該使用內建 Masonry 而不是 JS 庫，而是何時使用。 Masonry JS 庫非常棒，多年來一直在填補 Web 平台的空白，讓許多開發人員和用戶感到滿意。當然，如果將其與內建 Masonry 實作進行比較，它有一些缺點，但如果實現尚未準備好，那麼這些缺點並不重要。 對我來說，列出這些很酷的新網路平台功能很容易，因為我在瀏覽器供應商工作，因此我傾向於知道即將發生什麼。但開發人員經常在一次又一次的調查中表示，追蹤新事物很困難。保持資訊靈通是很困難的，而且公司並不總是優先考慮學習。 為了幫助解決這個問題，這裡有一些資源，它們以簡單而緊湊的方式提供更新，以便您可以快速獲得所需的資訊：
Web 平台具有瀏覽器網站： 您可能對其發行說明頁面感興趣。 而且，如果您喜歡 RSS，請查看發行說明提要以及基線新可用和廣泛可用提要。
網路平台狀態儀表板： 您可能會喜歡它的各種基線年份頁面。
Chrome 平台狀態的路線圖頁面。
如果您有更多時間，您可能也會對瀏覽器供應商的發行說明感興趣：
鍍鉻 邊緣 火狐瀏覽器 狩獵之旅
如需更多資源，請查看我的 Navigating the Web Platform Cheatsheet。 我的事情還沒有實現 這是問題的另一面。即使您確實找到了時間、精力和方法來進行跟踪，但在讓您的聲音被聽到並實現您最喜歡的功能方面仍然會感到沮喪。 也許您多年來一直在等待某個特定錯誤的解決，或者某個特定功能在瀏覽器中發布但仍然缺失。 我要說的是，瀏覽器供應商確實會傾聽。我是幾個跨組織團隊的一員，我們一直在討論開發人員的訊號和回饋。我們會查看許多不同的回饋來源，包括每個瀏覽器供應商的內部回饋以及論壇、開源專案、部落格和調查中的外部/公開回饋。而且，我們一直在努力為開發人員創造更好的方式來分享他們的特定需求和用例。 因此，如果可以的話，請向瀏覽器供應商提出更多要求，並向我們施壓，以實現您需要的功能。我知道這需要時間，而且也可能令人生畏（更不用說進入門檻很高），但它也有效。 您可以透過以下幾種方式讓您（或您公司）的聲音被聽到： 參加年度 JS 現況、CSS 現況和 HTML 現況調查。它們在瀏覽器供應商如何優先考慮其工作方面發揮著重要作用。 如果您需要跨瀏覽器一致地實作特定的基於標準的 API，請考慮在下一個 Interop 專案迭代中提交提案。這需要更多時間，但請考慮 Shopify 和 RUMvision 如何分享他們對 Interop 2026 的願望清單。這樣的詳細資訊對於瀏覽器供應商確定優先順序非常有用。 有關影響瀏覽器供應商的更多有用鏈接，請查看我的 Navigating the Web Platform Cheatsheet。 結論 最後，我希望這篇文章能給您留下一些值得思考的事情：
Masonry 和其他即將推出的網路功能令人興奮。 您可能想開始使用的一些網路功能。 您可以刪除一些自訂或第三方程式碼以支援內建功能。 追蹤即將發生的事情並影響瀏覽器供應商的幾種方法。
更重要的是，我希望我已經讓您相信充分利用網路平台的潛力的好處。
