为什么 CSS 网格不足以用于砌体布局

哈喽！大家好，很高兴又见面了，我是golang学习网的一名作者，今天由我给大家带来一篇《为什么 CSS 网格不足以用于砌体布局》，本文主要会讲到等等知识点，希望大家一起学习进步，也欢迎大家关注、点赞、收藏、转发! 下面就一起来看看吧！

前端开发者一直寻求简便易用的砌体布局方案。Pinterest 等网站的设计风格使得仅用 CSS 创建这类美观的动态网格变得异常困难。尽管最近有建议将砌体功能纳入 CSS 网格布局规范，但 Chrome 团队认为这并非最佳方案。以下阐述了我们认为砌体布局应拥有独立布局技术的原因，以及这将为开发者带来的潜在优势。

反对将砌体功能添加到 CSS 网格的理由

1. 性能瓶颈

CSS 网格和砌体布局处理项目排列的方式存在根本差异：

• CSS 网格: 所有项目在布局前已定位，浏览器可精确计算轨道大小和位置。
• 砌体: 项目按顺序排列，需要动态计算，尤其在混合固定轨道尺寸和自适应轨道尺寸时，容易造成严重的性能问题。

例如，考虑一个具有混合轨道定义的网格：grid-template-columns: 200px auto 200px。对于砌体布局，浏览器必须预先布局每种可能配置下的每个项目，大型网格的计算复杂度呈指数级增长。在使用子网格等高级功能时，问题更为突出。

为避免这种固有限制，我们建议将砌体布局与 CSS 网格分离。

2. 规范复杂化

将砌体功能合并到网格规范中会引入与格式化上下文核心原则相冲突的不一致性：

• 对齐属性: 网格支持六种对齐属性，但砌体可能仅使用其中一部分，类似于 Flexbox。
• 定位属性: 网格有四个定位属性（例如 grid-column-start），而砌体可能只需要两个。
• 轨道大小: 某些模式，例如 grid-template-columns: repeat(auto-fill, max-content) 在砌体中适用，但在网格中则无效。

这些差异会增加开发者的认知负担，需要记住不同上下文下的功能差异，从而导致混乱和错误。

提案：将砌体布局定义为独立布局方法

我们建议不要将砌体与 CSS 网格捆绑，而是使用 display: masonry 将其定义为独立的布局方法。此方法保留了开发者对网格的灵活性，同时避免了上述问题。

示例

标准砌体布局

使用以下代码实现相同大小列的简单砌体布局：

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

.span-2 {
  masonry-track: span 2; /* 跨两列 */
}

.placed {
  masonry-track: 2 / 5; /* 占据轨道 2、3 和 4 */
}

独立砌体布局的优势

• 清晰性: 开发者可以使用砌体布局，无需担心 CSS 网格兼容性的细微差别。
• 灵活性: 所有类似网格的功能仍然可用，无需引入新的约束。
• 可扩展性: 专用的砌体规范确保跨浏览器的行为一致性，并避免不必要的复杂性。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~