为什么 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中文网其他相关文章！