為什麼 CSS 網格不足以用於 Masonry 佈局

Web 開發者社群長期以來一直在尋求一種易於使用的方法來實現砌體佈局。由於 Pinterest 和相關設計，僅使用 CSS 來創建這些美觀的動態網格非常困難。 Chrome 團隊認為，儘管最近建議將砌體功能添加到 CSS 網格佈局規範中，但該策略可能不是最好的策略。以下是我們認為砌體應該有自己的佈局技術的一些原因以及對開發人員的一些潛在優勢。

反對將 Masonry 添加到 CSS 網格的案例

1。效能問題

CSS 網格和磚石佈局以根本不同的方式處理項目放置：

• CSS 網格：所有項目都在佈局之前放置，允許瀏覽器計算準確的軌道大小和位置。
• 磚石：專案按照佈局放置，需要動態計算，這在混合固定軌道尺寸和固有軌道尺寸時可能會導致嚴重的性能問題。

考慮一個具有混合軌道定義的網格，例如 grid-template-columns: 200px auto 200px。對於砌體，瀏覽器必須以每種可能的配置預先佈局每個項目，從而在大型網格中創建指數級的複雜性。當使用子網格等高級功能時，這尤其成問題。

為了避免發布具有此類固有限制的佈局方法，我們提出了一種將砌體與 CSS 網格分開的解決方案。

2。規範複雜度

將砌體合併到網格規範中會引入與格式化上下文的核心原則相衝突的不一致：

• 對齊屬性：Grid 支援六種對齊屬性，但 masonry 只會使用其中的一個子集，例如 Flexbox。
• 放置屬性：網格有四個放置屬性（例如 grid-column-start），而磚石只需要兩個。
• 軌道大小：某些模式，如網格模板列：重複（自動填充，最大內容）在砌體中有意義，但在網格中必須保持無效。

引入這些差異會增加開發人員的認知負擔，因為他們需要記住哪些功能在哪些情境中運作。這種碎片化可能會導致混亂和錯誤。

提案：砌體作為單獨的佈局方法

我們建議不要將 masonry 與 CSS Grid 捆綁在一起，而是使用 display: masonry 將其定義為獨立的佈局方法。這種方法保留了開發人員喜歡網格的所有靈活性，同時避免了上述陷阱。

範例

經典磚石佈置

可以透過以下方式實現具有相同大小列的簡單磚石佈局：

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, minmax(14rem, 1fr));
  gap: 1rem;
}

混合軌道尺寸

對於窄列和寬列交替的佈局：

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, minmax(14rem, 1fr));
  gap: 1rem;
}

自動調整大小的曲目

允許曲目根據內容自動調整大小：

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, minmax(8rem, 1fr) minmax(16rem, 2fr)) minmax(8rem, 1fr);
  gap: 1rem;
}

跨越與放置

使專案能夠跨越多個軌道：

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, auto);
  gap: 1rem;
}

單獨砌體佈局的好處

清晰度：開發人員可以使用砌體，而無需擔心 CSS 網格相容性的細微差別。

彈性：所有類似網格的功能仍然可用，而無需引入新的限制。

面向未來：專用的砌體規範可確保跨瀏覽器的一致行為，並避免不必要的複雜性。

以上是為什麼 CSS 網格不足以用於 Masonry 佈局的詳細內容。更多資訊請關注PHP中文網其他相關文章！