CSS 网格车道(Grid Lanes)布局

它来了——网页砌砖式布局的未来！在Mozilla奠定基础、苹果WebKit团队多年努力以及CSS工作组与各浏览器厂商多轮讨论后，其运作机制终于清晰呈现。

CSS Grid Lanes 正式登场。

.container {
  display: grid-lanes;
  grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
  gap: 16px;
}

立即在Safari Technology Preview 234中体验。

Grid Lanes 的工作原理

让我们详细解析如何创建这种经典布局。

首先是HTML部分。

<main class="container">
  <figure><img src="photo-1.jpg"></figure>
  <figure><img src="photo-2.jpg"></figure>
  <figure><img src="photo-3.jpg"></figure>
  <!-- etc -->
</main>

我们先为main元素应用display: grid-lanes属性，创建可实现此类布局的网格容器。接着通过grid-template-columns属性，借助CSS网格的全部功能构建“车道”。

本例中，通过 repeat(auto-fill, minmax(250px, 1fr)) 创建宽度至少250像素的弹性列。浏览器将自动分配列数以填满可用空间。

接着，gap: 16px 设置列间距为16像素，同时确保列内项目间距也保持16像素。

.container {
  display: grid-lanes;
  grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
  gap: 16px;
}

仅此而已！通过三行CSS代码，无需任何媒体查询或容器查询，我们就实现了适配所有屏幕尺寸的弹性布局。

不妨将其想象成高速公路上车流拥堵的场景。

如同经典的Masonry库，浏览器在决定项目位置时，会将下一个项目放置在最接近窗口顶部的列中。如同车流般，每辆车都会“变道”，最终进入能让它们“最靠前”的车道。

这种布局让用户能通过Tab键在各车道间跳转浏览所有可见内容(而非先滚动到折叠线下方第一列底部，再返回第二列顶部)。它还支持构建无限加载内容的网站——随着用户滚动页面，内容持续加载，无需JavaScript处理布局。

网格布局的强大之处

可变车道尺寸

由于网格车道充分利用CSS网格的全部功能，通过grid-template-*定义车道，因此能轻松实现创意设计变体。

例如，我们能实现窄宽列交替的弹性布局——即使列数随视口尺寸变化，首尾两列始终保持窄列。通过grid-template-columns: repeat(auto-fill, minmax(8rem, 1fr) minmax(16rem, 2fr)) minmax(8rem, 1fr)即可达成。

grid-template-* 语法蕴含无限可能。

跨列布局

既然拥有网格布局的全部能力，自然也能实现跨列布局。

main {
  display: grid-lanes;
  grid-template-columns: repeat(auto-fill, minmax(20ch, 1fr));
  gap: 2lh;
}
article { 
  grid-column: span 1; 
}
@media (1250px < width) {
  article:nth-child(1) { 
    grid-column: span 4;             
  }
  article:nth-child(2), article:nth-child(3), article:nth-child(4), article:nth-child(5), article:nth-child(6), article:nth-child(7), article:nth-child(8) { 
    grid-column: span 2; 
  }
}

所有文章摘要初始均设置为横跨1列。随后将首项明确设置为横跨4列，第2至8项则横跨2列。相较于过去十年主导的对称式布局(所有元素宽高统一)，这种设计创造出更具动态感的视觉效果。

元素定位

使用 Grid Lanes 时，我们也能精确定位项目。此处标题栏始终置于最后一列，无论存在多少列。

main {
  display: grid-lanes;
  grid-template-columns: repeat(auto-fill, minmax(24ch, 1fr));
}
header {
  grid-column: -3 / -1;
}

方向转换

是的，网格列可双向排列！上述示例均生成“瀑布式”布局，内容沿列垂直排列。但网格列同样能构建“砖形”布局，实现水平方向的排列。

当使用grid-template-columns定义列时，浏览器会自动生成瀑布式布局，例如：

.container {
  display: grid-lanes;
  grid-template-columns: 1fr 1fr 1fr 1fr;
}

若需实现反向的砖形布局，则需通过grid-template-rows定义行：

.container {
  display: grid-lanes;
  grid-template-rows: 1fr 1fr 1fr;
}

此效果得益于grid-auto-flow的新默认值normal。该值会根据您使用grid-template-columns还是grid-template-rows定义网格列，自动判断生成列或行布局。

CSS工作组仍在讨论应采用哪个属性来明确控制流向，以及该属性的语法形式。争议焦点在于是否复用grid-auto-flow属性，还是创建如grid-lanes-direction等新属性。若您想了解讨论方案或参与讨论，请参阅此讨论。

不过无论最终如何决定，normal都将是默认值，因此无需等待定论即可学习 Grid Lanes 。当仅定义单一方向(grid-template-rows或grid-template-columns)时，它将自动生效™。(若未生效，请检查grid-auto-flow是否设置了冲突值。必要时可unset该属性。

流向容差

“容差”是为网格车道引入的新概念，用于调节布局算法在决定项目位置时的严格程度。

请看下图。注意汽车4比汽车1略短。当“容差”为零时，汽车6会出现在最右侧车道，而汽车7位于左侧。汽车6最终出现在汽车4右后方，因为这样能使其在“道路”上更靠前(更接近网格容器顶部)。随后第7辆车占据次近顶部的空位，最终位于第1辆车左侧。最终结果？首组横向内容排列为1、2、3、4，次组则为7、5、6。

但车1与车4的长度差异微乎其微。车6距离页面顶部也未显著更近。将项目6置于右侧、项目7置于左侧的布局很可能造成用户体验偏差——尤其当用户通过Tab键浏览内容，或内容顺序带有标记时。

这些细微尺寸差异在实际应用中毫无意义。浏览器应将第1辆车和第4辆车的尺寸视为持平。因此flow-tolerance默认值设为1em——这意味着仅当内容长度差异超过1em时，系统才会重新计算下一项的排版位置。

若希望减少项目布局的变动，可提高flow-tolerance的数值。下图中将容差设为半辆车宽，导致车辆基本按从左到右的顺序排列，仅为避让超长豪华轿车才切换车道。此时内容的水平分组变为1、2、3、4与5、6、7。

可将容差理解为驾驶员的“从容程度”：他们会为领先几英寸而变道吗？还是只有在邻道有充足空间时才移动？你希望他们关注的空间大小，正是flow-tolerance的设定值。

请注意：使用Tab键浏览页面时，每个元素进入焦点都会高亮显示，且用户可能通过屏幕阅读器操作页面。过高的项目容差会导致布局跳跃体验生硬，过低则会造成不必要的频繁跳转。请根据内容尺寸及变化范围调整flow-tolerance值。

[注：本文初版发布时，该属性在规范及Safari Technology Preview 234版本中命名为item-tolerance。2026年1月7日，CSS工作组决议将名称更改为flow-tolerance。]

动手实践

立即在 Safari Technology Preview 234 中体验 Grid Lanes ！所有位于 webkit.org/demos/grid3 的演示均已更新为新语法，包含 Grid Lanes 的其他应用场景。它不仅适用于图片！例如，充满链接的巨型菜单页脚布局突然变得轻松自如。

.container {
  display: grid-lanes;
  grid-template-columns: repeat(auto-fill, minmax(max-content, 24ch));
  column-gap: 4lh;
}

后续计划

CSS工作组尚需敲定若干最终细节。但总体而言，本文所述功能已准备就绪。现在正是尝试的最佳时机，您终于可以放心将基础语法牢记于心了！

我们期待看到你的演示！展示你构想的新应用场景，并随时反馈发现的漏洞或改进建议。欢迎通过Bluesky或Mastodon联系Jen Simmons，分享链接、评论和创意。

自2022年中期起，我们的团队便致力于此项工作，在WebKit中实现该功能并制定网络标准。我们迫不及待想看到您将如何运用它。

共有{229}条精彩评论

向Safari团队致敬。今年十月他们突然跃居interop-2025榜首，着实让我们大吃一惊

https://wpt.fyi/interop-2025

此前未曾留意其追踪机制，但注意到自iOS 26起，Safari已新增大量卓越的网页功能。除WebGPU外，诸多细节改进如完善OPFS API缺失模块，使其真正具备实用价值。如今甚至新增了字段尺寸调整的CSS属性[0]，这在我看来弥补了CSS最明显的缺陷：无法让文本输入框自动扩展以适应输入内容！

[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P…

我以为contenteditable的纯文本模式本应解决这个问题。为何仍需手动调整字段尺寸？

`contenteditable`虽是HTML属性，但需依赖JavaScript才能发挥实际作用。此问题本质属于布局范畴——CSS的专长领域，因此`field-sizing`既能解决布局问题，又能让HTML表单元素继续承担实际输入功能。

至少重现他们的演示来展示修复方案。不过我觉得这答案可能会让人失望。

这似乎是Safari的惯常模式。重大版本发布时苹果总宣称Safari在X领域最出色，但其他时候却饱受诟病。我认为这源于Safari采用传统发布周期，而其他浏览器持续推送功能更新的差异。

相比其他浏览器，Safari的创新功能往往需要漫长周期才能落地。只需对比wpt.fyi上Safari的“稳定版”与“实验版”更新曲线即可。

除了“非我发明症”或“这不符合苹果风格，我们宁愿让操作系统团队(以及市场部门)主导发布周期，用户死活不管”这种态度外，我实在想不出他们拒绝采用4/6周“常青”更新模式的正当理由。

这简直是毫无必要的自摆乌龙。

网络平台无需如此快速迭代。谷歌常单方面推出新功能并宣称其为标准。我认为网络不应以超越真正开源社区项目跟进速度的节奏变革。我不认同网络已沦为依赖数十亿美元企业恩赐的现状。

我承认这观点颇具争议，但谷歌的做法本质上是*“拥抱并扩展”*策略的变体。传统上这指专有扩展(如VBScript)，而如今这种微妙变体同样会引发类似后果。

我明白如今流行将对Chromium的偏见强行塞进任何相关话题，但此刻我讨论的是Safari的兼容性修复、漏洞修复及功能改进——从开发完成到用户端落地存在漫长延迟。即便Chrome从未存在，我仍会提出相同论点。感谢你再次重提这个“争议性观点”的第10001次复刻版。

WebKit被要求兼容的实体行为绝非“牵强附会”，而是切中要害。这绝不亚于那些模糊指责苹果患有“不创新综合症”或营销优先论的批评。你批评苹果缺乏快速发布周期；而我批判的正是快速发布周期本身(安全补丁除外)。

网络平台无需如此急功近利。

你怎能辩称Safari因缺乏频繁更新而长期渲染故障网站是好事？

“扭曲场效应”这句老生常谈在此恰如其分。

就像当年Safari不支持WebGPU被吹捧为特色功能，如今支持了WebGPU又突然变成特色功能。对某些人而言苹果永远正确——他们做的事是特色功能，不做的事也是特色功能。

我认同许多公司会引发狂热支持者偶尔做出奇怪的反射性辩护。所幸拙劣的论点不具传递性。

暗示相反观点本身就是拙劣的论点。

Safari确实存在值得批评的滞后现象，某些功能实现不完整或存在缺陷。但所谓“网站崩溃”的指控，往往只是开发者偷懒的证据——他们既未在Chrome之外进行测试，也未实现优雅的降级方案。在我看来，在浏览器尚未广泛采用前就依赖尖端Chromium功能，实则是对新奇性胜过稳定性的迷恋。更甚者，这无异于冷酷无情地抛弃开放网络平台，转而拥抱Chrome平台。网页开发者固然自由选择，但将部分开发者的糟糕决策或懒惰归咎于浏览器，实属误导。

> 但许多所谓“网站崩溃”的指控，本质上只是开发者偷懒的证据——他们既不测试Chrome以外的浏览器，也不实现优雅的降级方案。

确实如此。人们总是优先测试Chrome，甚至仅测试Chrome。这种情况永远不会改变，因为人性本懒惰，而且存在大量网站对兼容性重视程度参差不齐，又缺乏能强制执行标准的权威机构。即便其他浏览器采用不同方案，他们也只会测试该方案。

解决方案在于规范化测试和wpt.fyi项目。它为实现公认标准的完美兼容性提供了路径，更将引领未来——届时浏览器间的差异将仅限于刻意设计(如WebMIDI)。绝妙。

正因如此，我希望Safari测试版与正式版在wpt.fyi评分上的差距能缩小。道理很简单！

为何总将bug修复与新平台特性混为一谈？

因为此类bug主要集中在当时的新平台特性中。

作为网页开发者，我深切理解大家对十年前Safari的Flexbox漏洞和近年视口漏洞的沮丧。我也记得Chrome的漏洞曾令人抓狂——比如令人发狂的滚动锚定行为、亚像素取整不一致，以及持续存在多年的position:fixed漏洞，这些漏洞存在时间之久，反而成了其他浏览器不得不遵循的事实标准。所有浏览器都存在缺陷。若认为Safari尤其糟糕，不过是戴着Chrome有色眼镜看待历史罢了。

我并非否认其他浏览器没有缺陷。本讨论的核心在于Safari因发布周期缓慢而长期未能修复问题。

你假设Safari长期不修复漏洞是因为“发布周期缓慢”。或许某些漏洞本身复杂，需要时间解决。谷歌项目虽拥有浏览器领域最雄厚的预算和极快的发布节奏，却耗费数年才修复我之前提到的漏洞(以及许多其他漏洞)。

不，很多问题其实相当简单，这正是我感到不满的原因。我指的是诸如“因尺寸计算疏漏导致特定功能的SVG无法正确渲染”这类问题，而非“能否在下个版本周期实现WebGPU”这类需求。

> 你怎么能把Safari因缺乏频繁更新而长期渲染故障网站的行为说成好事？

这种情况几年前就不存在了。

即便现在，当网站在Safari中出现故障时，通常是因为该网站使用了Chrome专属功能——这些功能尚未在Safari或Firefox中实现。开发者需要被提醒渐进增强的重要性。

某些网页开发者仅在Chrome上测试网站，这毫无道理——毕竟移动版Safari在美国市场占有率约50%[1]，全球占比约21%[2]。

> 正如当年Safari不支持WebGPU被吹捧为特色功能，如今支持后WebGPU却突然成了标准功能。

我可能忽略了这点，但关注者都清楚：早在WebGPU正式化之前，Safari就已通过开发者选项提供该功能，它始终在成为真正特性之路上稳步推进。

[1]: https://gs.statcounter.com/browser-market-share/mobile/unite…

[2]: https://gs.statcounter.com/browser-market-share/mobile/world…

“谷歌吸取了微软的教训，采取了一种新颖的’拥抱、扩展、消灭’策略——打破网络并践踏数据位。只要我们前进，谁在乎它是否崩溃。” https://www.quirksmode.org/blog/archives/2021/08/breaking_th…

好文章。感谢分享。

VBScript这个词好久没听到了！让人想起当年编辑5000行.asp文件找if语句，接着又得翻1000行HTML代码的日子。可惜20多年后的网页开发并未真正进步，只是换了种形式罢了…

设备上的网页平台必须锁定特定版本，因为操作系统已停止更新。一旦系统停止更新，你就该买新设备了。

不该允许用户在旧设备上使用新版浏览器——尤其是第三方浏览器，因为这会影响苹果iPad的销量。

> 除了“非我发明症”或“这不符合苹果风格，我们更倾向于让操作系统团队(以及市场部门)主导发布周期，用户死活不管”之外，我实在想不出他们不采用“常青”的4/6周更新模式的正当理由。

macOS平台的Safari技术预览版[1]每两周就会推出新版本。

每年九月，Safari都会为macOS、iOS、iPadOS和visionOS发布新版本。这一发布周期已持续多年。自2025年9月15日Safari 26发布以来，这些平台已迎来两次更新：

11月3日发布Safari 26.1，12月12日发布26.2。

今年Safari团队共发布7个版本，平均间隔7.5周；与4-6周的周期差异不大。macOS版Safari每次重大更新均兼容当前macOS版本(Tahoe)及前两个版本——Sequoia和Sonoma。

顺带一提，2024年共发布9个Safari版本，平均间隔5.8周。

这并非Safari首次抢先其他浏览器推出重大新功能：例如:has()查询器、Display P3色彩支持、JPEG-XL等特性。归根结底，其发布节奏不受内部创新恐惧症或市场团队的制约。

[1]: https://webkit.org/downloads/

Safari/WebKit团队确实表现出色。

我将Safari设为默认浏览器，但和所有Firefox/Safari用户一样，仍会遇到Chrome中不存在的bug(显然不包括WebMIDI问题)。看着wpt.fyi上稳定版Safari与尖端WebKit版本间长达7周半的30个版本差距，实在令人沮丧。更短的修复周期能为普通用户带来更佳浏览体验，这是不争的事实。被迫等待macOS更新，这无疑在无谓地拖累浏览器发展。

> 被迫等待macOS更新，这无疑在无谓地拖累浏览器发展。

Safari本质上是操作系统组件——许多人似乎未能理解这一点；数十万第三方应用都依赖Safari的WebKit引擎。

我从未听闻普通Safari用户抱怨更新不够及时——这才是网页和应用开发者关心的问题…因此Safari技术预览版每两周发布一次。

即便iOS、iPadOS和macOS上的正式版Safari，也允许启用仍在开发中的网页功能。

这些漏洞未必是浏览器的责任。

Safari的更新频率已远超以往。我个人不满的是其扩展管理策略——强迫所有开发者经历App Store地狱般的审核流程。

> 今年十月他们突然跃居interop-2025榜首时，着实令我们大吃一惊

并非所有人都感到意外；我们中有些人早已注意到Safari团队持续数年在交付最新的HTML和CSS特性。

这其实不足为奇。当Chrome团队忙着推广WebPCIe之类的技术时，Safari早已在交付用户真正需要的功能——比如模糊背景效果，比其他浏览器早了整整数年。

试想若Chromium/Blink工程师大军能倾力优化所有人都在使用的核心组件，而非只服务于极少数网站和应用的利基功能，会是何等景象。

嗯，我知道Safari不支持64位WebAssembly——这是Chrome和Firefox都具备的重要特性，但这似乎表明他们实现了“100% WebAssembly支持”。

https://webassembly.org/features/

互操作性测试是预先选定的子集(如今主要由开发者在GitHub问题中投票决定)。这表明Safari在互操作性-25协议约定的测试子集中已达100%覆盖率。点击菜单中的该项可查看具体测试内容，跳转至：

https://wpt.fyi/results/wasm/jsapi?label=experimental&label=…

完整的wasm测试套件在此：

https://wpt.fyi/results/wasm

这个追踪器太有意思了。2025年初几乎所有浏览器的互操作性都低于80%，到年底却都突破了98%？这凝聚了众多团队的非凡成就，令人惊叹！

需澄清测量标准：这并非指所有功能都达到98%互操作性，而是针对2025年特定目标集的达成率(即便如此仍相当出色！)

我认为他们意识到功能发布不同步会导致所有浏览器都采用前无人能使用，这耗费数年时间，因此现在采取协调机制

上述所有因素甚至更重要的是确保这些功能在成员浏览器中表现完全一致。

这张图表很棒。结合Interop 2024的演示，确实很好地呈现了我认为的重要改进。我最初注意到的是Safari 18和Safari 18.2，随后是Safari 26，现在到了26.2版本，那些曾经运行不畅的网站如今全都正常工作了。关键在于自Safari 26.2发布以来，我几乎无需切换到Chrome或Firefox进行测试——而此前每月甚至每季度都需如此操作。

期待未来版本能优化Safari的多标签页性能，使其更流畅高效。Firefox的多标签功能值得借鉴之处甚多。

Safari曾一度沦为新版IE，其CSS动画和SVG元素的问题简直层出不穷。

好在他们正努力改善Safari的糟糕体验。

Safari依然是新版IE。准确说并非“新版”，它始终就是IE。作为唯一存续的非常青浏览器，每次讨论Safari时为何不提及这点？当真正重要的版本永远停留在某款老旧iPhone上(仍有n%用户在用)，所有标准实现都毫无意义。

Caniuse毫无意义，他们新推出的“基准”评分同样毫无意义；只要足够多用户在官方支持终止后继续使用(完全正常运作的)iPhone，且无法安装其他浏览器(引擎)，这便是决定采用何种浏览器功能时唯一需要关注的数据点。

iPhone或iOS拥有全球最高的系统升级率。约85%+用户运行iOS 18及以上版本。Liquid Glass iOS是首次出现更新滞后现象。但苹果通常能在系统生命周期结束时(即今年8/9月)实现近80%或更高的最新iOS普及率。

有人可能认为iOS版Safari应像macOS那样支持独立更新，但当前更新速度已不算太差。

认为Safari是新版IE的人，都是没经历过IE时代的人。

Safari不可能成为新版IE，因为它不具备95%的市场份额。而IE的独特问题在于强推仅自身支持的功能，Safari的问题恰恰是某些功能不支持。

更关键的是，Safari和Firefox支持的许多功能Chrome反而缺失。但没人抱怨这些功能缺失，因为用户根本不会尝试使用Chrome不支持的功能

> 只有没经历过IE时代的人才会认为Safari是新版IE。

完全正确！我自己也多次说过同样的话。

当有人问“你没在90年代做过网页开发，根本不懂自己在说什么吧？”时，回答“Safari就是新版IE”就是最完美的回应方式。

希望他们尽快支持WebTransport协议。

互操作性2026提案现已开放投票。我看到有人提交了相关提案

https://github.com/web-platform-tests/interop/issues/1121

最期待的就是终于支持arbitrary-subdomain.localhost了。之前为Safari添加专属回退方案简直烦死人。

哦，这绝对是好消息！有官方公告了吗？

如果省略宽高属性(因为在父容器中控制尺寸)，SVG是否仍会展开为全尺寸？去他妈的Safari

不知Ladybird是否已尝试运行这些互操作性测试？或者这些只是WPT的子集？

你可以编辑表格中的“产品”列表，将“Ladybird”加入其中。[1]

他们的测试结果是：1974740 / 2152733 (91%)

他们还设有专属仪表盘追踪数据[2]

[1] https://wpt.fyi/results/?product=ladybird

[2] https://grafana.app.ladybird.org/public-dashboards/2365098a1…

以下是包含三大平台(Ladybird、Servo和Flow)的对比分析

https://wpt.fyi/results/?label=master&product=chrome&product…

回答你的问题：是的。苹果要求浏览器在web-platforms-test测试套件中通过80%的测试才能被视为iOS的有效浏览器，因此他们专门针对该套件优化以达到这一门槛

这个要求相当荒谬，因为wpt本就不代表所有网页平台标准。其中包含非标准功能的测试，且多数测试只是简单的Unicode字符渲染验证。

我以为iOS上不能提供其他浏览器引擎。所以没有Ladybird引擎，没有Servo，没有Gecko，没有Blink，只有WebKit。

某些地区已宣布禁止iOS使用其他操作系统引擎属于反竞争行为，因此要求苹果开放支持。

苹果正竭力抗争，而为其他引擎设置门槛正是其抗争策略之一。

直到数月前欧盟裁决前确实如此。目前iOS仍仅支持WebKit运行，但苹果正着手改变这一现状。

它们确实只是WPT的子集。不过在“互操作性”评分中，子测试的权重计算方式略有不同。

interop-2025。这并不意味着Safari支持所有最新特性，而是表示“针对某些小范围特性，支持率达到多少百分比”。

当然，Safari会竭力将不愿支持的功能排除在该子集之外。

真希望他们能发布CSS间隙装饰功能：https://developer.chrome.com/blog/gap-decorations

我厌倦了用笨拙的权宜之计来实现弹性布局/网格元素间美观的边框。

考虑过用表格吗？

有趣的是，尽管现状已远胜从前，我们却总在不断索求更多。难道我们永远无法满足于现有成果吗？

> 尽管现状已远胜从前，我们却总在索求更多，这实在耐人寻味。

从事网页开发十五载，有时真难以置信这类评论。过去的开发环境绝非“远胜从前”——CSS糟糕透顶，仅为三种设备适配就令人痛苦不堪。

表格结构毫无语义价值，无法支持小数单位。移动端重排布局根本不可能实现，只能靠拆分表格这类JS权宜之计。原生环境下更无法实现元素重新排序。

从事网页开发二十载的我，同样难以置信这类言论。

弹性布局与网格系统实现的版式设计，早已远超表格布局的极限。任何持相反观点者显然从未进行过严肃的实际前端UI设计与开发。

Flex和网格是否存在我期待的开发体验优化？当然。语法是否偶尔显得晦涩？确实。但其核心力量毋庸置疑，任何否认者要么是无知的后端开发者，要么就是想用MS Word设计界面的喷子。

说实话，原文提到“我们比以前好太多了”，我觉得他们其实认同你的观点

最近在HN看到类似评论，说CSS在过去“更好用”，如今的技术要么多余要么太复杂。

我提醒那人：在Flexbox和CSS网格诞生前，我们只能靠浮动定位技巧和滥用HTML表格来排版。

当时根本没有简单方法能居中一个div！

> 我们现在已经比以前好太多了

他们指的是当下。“我们现在比过去好太多了。”

表格能解决他们讨论的问题吗？

表格单元格的边框可独立于内容应用。
间距装饰能实现弹性/网格项间的边框效果，却无需应对表格的怪癖与行为问题。

常见应用场景包括模拟印刷版式设计模式——尤其报纸和菜单中的分隔效果，用于划分信息组块。

示例：https://developer.chrome.com/blog/gap-decorations

看到这个真令人兴奋！上周我刚在项目中使用过Masonry布局。虽然它运行良好且性能出色，但依赖绝对定位的实现方式颇为hack，需要预先知道对象的宽高比才能实现平滑布局，且每次调整尺寸都需重新计算。期待未来能有通用原生方案问世。

我也是。我太喜欢Masonry布局了，等不及CSS解决这个问题，所以从2019年起就盼着能从主页移除最后1.3KB的JavaScript代码。

感谢所有为此付出努力的人。

其实存在无需指定每个元素x,y坐标的砖墙布局方案。https://codepen.io/mmis1000/pen/gOyZJqE

新增元素仍需指定尺寸并使用少量JavaScript(整页未混淆的JavaScript代码少于100行)，但尺寸调整可通过CSS自然实现。

我认为核心问题在于多数人缺乏明确的马赛克布局规范，因而也难以实现理想效果。

仅使用纯CSS网格即可创建基础的砖砌式布局。但具体取决于使用场景。以这个示例为例，其中混合了无图片的纯文本卡片、含图片的纯文本卡片以及图文并茂的卡片。

https://codepen.io/zardoz89/pen/KKVEGbw

我一直觉得马赛克布局虽然美观，却不利于快速浏览图片内容。

许多网页“设计”更注重视觉效果而非可用性。没有任何利益相关者会停下来实际使用产品，他们只是上下滚动，欣赏毫无意义的“滚动进入”动画，然后说“酷毙了”。至于那些透明度50%的文本，除非滚动到指定位置否则无法显示——反正没人会真正尝试阅读它们。

> 没有任何利益相关者会真正停下来使用产品，他们只是上下滚动，欣赏毫无意义的“滚动进入”动画，然后说“酷毙了”。

实际上他们确实如此。他们喜欢动画效果，而某些人(尤其是开发者)则不然。但他们不会多次使用，因为第一次体验后就会发现这种设计有多烦人。

最大问题在于：当图片比例统一时效果尚可，但混用不同比例时就行不通了。

砖砌布局的意义正在于处理不同宽高比。否则它就只是普通网格布局。

砖砌布局会固定其中一个维度。这意味着纵向或横向图片会明显小于反向比例的图片，因为其长边必须与后者的短边等长。

当相同方向的图片存在不同比例时，砖砌布局效果最佳。

好奇问下，有什么算法能处理任意方向、尺寸和比例的图片布局？这似乎是个相当棘手的问题。或许可以尝试背包问题变体？

此类布局可利用flexbox实现：https://bfgeek.com/flexbox-image-gallery/

虽然不清楚最佳方案是什么，但我个人希望每张图片都能与其他图片保持正确相对位置。这意味着布局会显得参差不齐，但好处是能轻松定位特定图片——就像编程时通过代码的“形态”快速滚动查找函数定义那样。

以下是我满意的相册流布局示例：

https://frifoto.emilbratt.no/?view_mode=photo-stream&tag=All…

什么？

砖砌布局的核心特性在于支持混合纵横比。这正是其精髓所在。若未混合横竖向图片，就不该使用砖砌布局。

砖墙布局会固定其中一个维度。这意味着纵向或横向图片都会比反向比例的图片明显更小(细节更少、更容易被忽略等)，因为它们的长边必须与后者的短边等长。这会带来真实的用户体验问题。砖墙布局最适合处理的是比例不同但方向相同的图片。

指出砖墙布局在混合方向内容上不如统一方向内容表现出色固然正确，但我们仍需解决混合方向内容的展示问题。你建议采用哪些替代方案？

– 若将所有图片拉伸至统一宽高比，画面会严重变形且效果糟糕。

– 若裁剪所有图片至统一宽高比，部分图片可能损失大部分内容。
– 若按原始宽高比全尺寸显示，图片间会出现大片空白区域，因其无法紧密排列。

砖墙布局能在不浪费用户大量屏幕空间的前提下保留宽高比。虽非完美，但这是我所知处理混合方向内容的最佳方案。

若您有更优的混合方向处理方案，我乐意听取并撤回上述言论。

Danbooru[1]及其衍生图片论坛对此处理得恰到好处，相较于Pinterest的糟糕体验，浏览起来堪称享受。图片间留有空白区域，这完全没问题。屏幕本就不必填满每个像素点——正因如此我们才发明了“边距”这种神奇设计，元素需要呼吸的空间。

[1]https://safebooru.donmai.us/(注：此为Danbooru的“安全”子集供参考，但仍不适合工作场所)

这样有什么好处？它依然只是一个由图片组成的网格，这些图片似乎都被限制在或多或少的矩形网格中。我更倾向于动态网格，其中横向和纵向图片的尺寸可以混合排列。

关键在于动态图片网格实际上并不利于用户体验。表面看来或许更具视觉吸引力，但实际浏览图片时，可预测性才是关键。即便采用混合方向的图片布局，在图片间预留额外留白也无济于事。当视线能稳定地逐行扫描内容时，用户消化信息的效果远胜于在动态网格中四处跳跃追踪内容流。

本帖评论者为何执着于“逐行扫描”？用户浏览图片库时通常会跳跃式浏览——双眼先整体摄入所有选项，再锁定感兴趣内容。我从未见过或听说有人会逐行浏览图片库或报纸版面，这种行为对普通用户而言实属异常。

我怀疑若能获取眼动追踪测试数据，用户偏好将呈现极其清晰的规律。我浏览图片库的方式与快速阅读文本如出一辙——通过有序的视线路径实现“阅读”所有图片而不重复观看，仅在特定元素吸引注意力时停驻。随意堆砌垃圾内容会让画面混杂难辨，迫使我的视线反复扫过相同区域——既要辨认细节，又要确认已浏览与未浏览的内容。这种版式本身在索取注意力，而非让视线自然沉浸于图片本身。

根据Hotjar等工具的实际眼动追踪数据，用户确实会在页面上跳跃浏览。线性扫描者虽属少数，但在HN上可能占比更高——这本就是常态。

我认为这是重大进步，但若能更灵活地混合纵横比就更好了…

设想采用与原帖类似的布局，但横向图片能跨多列显示，同时保留现有功能。

砖墙布局的精髓在于适应图片尺寸。若已知图片尺寸，现阶段用Flexbox实现砖墙布局并非难事(https://github.com/hannasm/masonflexjs)。但若要实现真正的马赛克式布局，则需突破现有技术框架。不过此时可能较难创建完美适配的布局配置，或需大量空白区域才能实现美观排版。

有点突兀，但为何在链接的仓库中使用.NET Core来压缩JavaScript文件？纯粹好奇。在我看来这似乎有些大材小用。

结合Masonry布局与装箱算法，根据视觉需求，可(或应？)采用尺寸系统来调整布局元素：例如当尺寸元素占基础宽度的四分之一时，可缩小部分最宽图像以增强统一性；反之也可通过放大某些元素来创造节奏感。

编辑：文档中的首个示例https://masonry.desandro.com/layout可供参考，但需将图像尺寸想象成实际的两倍，类似于Müller Brockmann网格布局

或许这是个不受欢迎的观点，但我实在不喜欢车道式布局，因为它无法让人高效地逐个浏览列表中的所有元素。

若尝试从左至右浏览，很快就会发现每行末尾难以辨识下一行的起始位置。很容易误踩原行(重复查看相同元素)，或无意中跳过某行。逐项浏览需要耗费大量认知精力，视线不断上下跳跃，最终导致重复查看相同元素。

若尝试从上至下逐栏浏览，又会发现页面支持无限滚动，导致永远无法越过首栏。

但当无需系统性逐项检查时，车道式布局效果极佳。Pinterest等网站采用此布局，正是因为其内容无需系统性浏览，而是供用户快速浏览获取。若你的内容确实需要系统性浏览，采用通道布局将是糟糕的用户体验选择。但通道布局可能被误用，并不意味着它本身就是糟糕的布局方案。

我觉得这属于那种看起来不错，但实际使用起来很烦人的东西。

我个人觉得这东西根本就不好用。它只是看起来“不错”(主观评价)。

大尺寸图片占据主导地位，炫目的图像变得更重要以吸引注意力(如果目的是让图片成为焦点的话)。这简直是极其糟糕的信息呈现方式。

幸好这个功能刚好赶上过时！从用户体验角度看，这布局实在糟糕透顶。不过至少乍看还挺漂亮！

它本就不追求“效率”，而是让视线能扫过整页快速定位目标。就像报纸或图片库的设计思路。

充满“右脑思维”的体验。我向来主张大脑两半球均衡发展。适合Pinterest这类网站，也适用于Home Assistant。

这些公告带着悲喜剧色彩。虽然功能本身令人惊叹，但众所周知，由于苹果公司强迫用户使用其浏览器却不提供持续更新，任何新浏览器功能都无法在短期内稳定使用。

两代之前的iOS版本无法获得最新版Safari？

我无法验证，因为我妻子的iPhone据她遗憾地表示“已更新至最新glAss版本”。

我有个客户抱怨几年前的iPad无法运行某些功能。所以…我不清楚具体截止标准，但显然并非所有设备都能定期更新。他尝试手动更新也未成功。

上周Safari刚有大更新。

是所有设备都更新了Safari？还是仅限苹果认可的设备？通常苹果只给新机型推送Safari更新。

你觉得六年前的手机算新机型吗？那七年的Mac呢？

我认为iPhone X是最新款不再接收iOS更新的机型。它发布于2017年，距今已有八年。

如果我遇到需要阅读网页上那些尺寸位置随机的文本网格，求求谁来枪毙我吧。https://webkit.org/wp-content/uploads/Grid-Lanes-newspaper-d…

没读过报纸吗？

(非GP用户)我对砖墙式布局本身并无异议，但报纸受纸张尺寸限制，必须尽可能压缩内容(以最大化“信息”传播量)。而屏幕理论上是无限的(尽管报刊亭屏幕除外)。

我确实有个图片密集的网站，目前所有内容都采用三列并排网格布局…

屏幕虽无限，信息仍需分级呈现——这正是报纸采用不同标题字号的原因。若真要塞满所有内容，本可用统一小字体节省纸张，但读者需要通过字号差异快速辨别重要信息，这正是字号分级的初衷。无限屏幕亦无二致，信息优先级的设计原则依然适用。

是的，我接触过。印刷品本质上属于完全不同的媒介类型，具有截然不同的特性。

另有人提出相同观点，我已在https://news.ycombinator.com/item?id=46331586#46334242中回应。

简而言之：在用户视角中，报纸与这类布局并无本质区别——若普通用户能浏览数百年的报纸，自然也能驾驭后者。

但关键在于，网页的数字化呈现与报纸的实体形态属于根本不同的媒介载体，理应区别对待。纯文本墙本身并非坏事，但在显示器(更别提手机或平板)上呈现时，会造成糟糕的用户体验。

当然可以区别对待，但在特定使用场景和版式设计中，也可采用统一处理方式。关键取决于设计目标。

我同意，这似乎违背了设计中最基本的理念，比如最小化意外性，以及通过分组+对齐为读者提供上下文。

我也觉得这设计很棒。终于实现了报纸版式的效率——没有强制的对称性，内容在最佳空间中自然分布。我想要。

看起来很漂亮，但基本可用性失败了。

读完左上角标题为“为Spedometer 3.0优化Webkit与Safari”的文本块后，我他妈接下来该读什么？难道要我逐列递归地读？还是得盯着像素点，分辨哪些区块位置更高，然后在页面上左右乱跳？参考图示：https://imgur.com/a/0wHMmBG

在缺乏双固定轴的媒介上，列式布局本质上就是个破玩意儿。网页布局会让其中一条轴无限扩展以适应内容，因此根本不存在合理的算法来排版任意内容。结果要么是项目顺序混乱不堪，要么就是得在整页上下反复滚动——而页面长度可能无限延伸。两种方案都糟糕透顶。更别提它与“无限滚动”功能的糟糕交互体验了。

并非所有内容都需要按顺序阅读。这种布局适用于希望引导用户自由阅读的内容场景。所以若顺序让你困惑，很可能原本就无需固定顺序。例如谷歌图片搜索时，系统会推测相关性排序，但采用密集布局让你能用眼睛快速扫描，自行判断最相关的内容。无论你选择从左到右、从上到下、随机浏览、由下而上还是其他方式，完全由你决定。

若将此布局用于小说等文本内容，用户体验将极差。但用于图片库？或无优先级的随机文章集？何乐而不为？

> 对于不具备双固定尺寸轴的媒介，列式布局本质上存在缺陷。

你可以使用传统的CSS列布局(不具备新版网格布局自动“砌砖式”排列功能，仅顺序显示内容)，并实现水平滚动。但水平滚动对多数输入设备而言操作繁琐，因此新版“紧凑型”列布局能有效解决垂直滚动固定宽度区域的笨拙问题。

> 我他妈接下来该看哪篇？

真是奇怪的评论。接下来看什么由你决定，你读过报纸吗？你只需浏览所有内容，挑选感兴趣的文章阅读即可。我不理解这些评论，这种布局在现实中完全可行(而且固定尺寸是人为设定的，我也能制作超宽或超长的报纸，轴向尺寸并不影响此类布局，无限滚动就是例证——毕竟屏幕上任何时刻显示的内容量都是固定的)。

> 你先快速浏览所有内容，再挑选感兴趣的文章

好的。我该按什么顺序浏览才能避免跳过内容？按列浏览会导致部分框被截断，需要后续重新检查；而横向浏览则需要逐个标记已查看的框，无法像单一指针那样直观显示“当前浏览进度”。另一种方案是粗略地从左到右、从上到下扫描，接受遗漏部分区块的风险。但这同样不理想——毕竟若你认为我不需要查看所有内容，当初就不该把它们都排版在页面上。

你说得对，确实可以设计出极难阅读的报纸，但你不会这么做，因为最终失败的案例就是CSS网格通道。

这太可笑了，我都不知道该说什么了。你可以对报纸提出同样的问题，但99%的人照样能轻松阅读。我认为问题出在你身上——你执着于寻找扫描多尺寸内容页面的精确算法；实际上人们只是快速浏览，在脑海中记录哪些内容看过了哪些没看。

报纸的阅读逻辑很简单：从最左侧栏开始线性扫描至页面底部，接着读下一栏，如此循环直至页尾。整个过程中你只需记住“目前阅读进度”，确保不遗漏内容即可。报纸采用列式布局的合理性在于：两个维度(纵向与横向)尺寸固定，读者只需进行一次循环往复的线性扫描即可。

如果其中一个轴是固定的——网格车道就是这种情况(毕竟它不像Figma那样是完全可平移的无限画布)——你只需持续读取当前屏幕上的内容，然后进行滚动。我实在看不出这与之前提到的长篇报纸有何不同：每张“报纸”相当于一个“屏幕”，两者原理相通。这本质上就是无限滚动机制，无论纵向还是横向，区别仅在于列表中显示的项目数量。若真要吹毛求疵，Figma用户即便在无限可平移画布中，也能完美保持内容语境的认知。再者，报纸读者通常不会按你所说的逐栏扫描，而是先扫视所有标题，挑选感兴趣的再阅读对应文章——这本就是自由浏览的过程。

因此我仍坚持认为，这对普通读者并非问题。实在看不出来你所说的困难究竟何在。

> 在报纸上答案很简单。你只需沿着最左侧的栏目从上到下逐行浏览[…]

你当真认为人们是这样读报纸的吗？

有趣，我觉得这排版美极了！

让人联想到NYTimes.com…

你有什么问题？

自从在浏览器设置里发现砖墙布局(用于我的个人书签网站)后，我就一直用它。

grid-template-rows: masonry;

那这个设置要过时了吗？

没错，这场持续多年的争论最终以这样的结论收场：“我们进行了你不知情的投票，决定淘汰砖墙布局。若你介意，本该参与那场你毫不知情的投票。现在改变为时已晚。”

https://m.youtube.com/watch?v=yikbSQ6tvlE

> 我们举行了一次你未曾知晓的投票，并决定取消砖砌布局。若你真在乎，就该参与那场你毫不知情的投票。现在改变已为时过晚。

我认为这是对事件的极其刻薄的描述。WebKit团队过去18个月里反复公开呼吁大家参与这项决策。

> 协助我们开发CSS网格第3级规范(即“Masonry”布局)

> 附：关于命名问题

> “Masonry”可能并非此新特性的最佳名称[…]。CSS工作组正在[此议题]中讨论命名方案。若有命名建议或偏好，请加入讨论。

— https://webkit.org/blog/15269/help-us-invent-masonry-layouts…

> 协助确定CSS中Masonry布局的最终语法规范

> 我们同时建议将masonry属性重命名。

> 如先前文章所述，“masonry”并非理想名称——它仅是隐喻而非功能直译，且并非此类布局的通用称谓。多数开发者更倾向称其为“瀑布式布局”，同样属于隐喻表达。

> 各位提出了诸多更优命名方案，其中“collapse”与“pack”尤为突出——即grid-template-rows: collapse或grid-template-rows: pack。您更倾向哪个？或有其他建议？请在[此议题]下专门针对新值名称(用于“直接使用网格”选项)发表评论。

— https://webkit.org/blog/16026/css-masonry-syntax/#footnote-1

> [css-grid-3] 重命名masonry关键字

— https://github.com/w3c/csswg-drafts/issues/9733

这场争论持续了数年，密切关注它简直是在浪费时间。就连子网格的讨论似乎也完全陷入停滞。我认为在投票讨论之前，很多人早就放弃关注了。我就是其中之一。

但如果你是主动放弃关注的人，那么将投票信息传达不力归咎于他人，是否有些不厚道？保持信息同步难道不是你的责任吗？

他们总不能专门去联系所有曾经可能关心此事的人来参与讨论吧。

我明白你的意思，但无休止的争论和延续“辩论”本身就是一种策略。那本中情局破坏手册里关于会议的章节，简直如出一辙。这类争论的持续时间通常不是以小时、天或周计，而是以年为单位。而那些拖延战局、死守争端的人，正是为此全职雇佣的。

事态发展到我几乎认定子网格已死。FF实现了该功能，但多年间再无他人跟进。

我们选择置身事外是否该自责？没错。但正是某些策略导致了这种局面。我坦然承认自己选择了旁观，但这场消耗战的发起者，正是那些甘愿无限期阻挠进步的人。

这就是你想要的决策方式吗？

说到底，我并不在乎你们如何称呼砌体功能。但围绕名称的争论堪称极端化的“自行车棚效应”。我宁愿放弃语义之争，早些解决这些无谓争议并推出功能。如今我们距离实际投入生产使用仍遥遥无期。

我已不再等待企业、委员会或项目改变方向。当一群人从根本上否定我所需功能的存在价值时，我毫无动力去推动共识形成——何必徒劳？我更愿意将时间投入开发用户真正需要的功能。

这听起来很像阴谋论。

无论是公司还是员工，都没有拖延讨论的动机，尤其针对如此琐碎的事项。更明智的做法是加速推进，在可接受的时间框架内完成任务。

况且，若你认为此事不值得投入时间，何必诋毁其为秘密策划？你本可以像其他参与者那样出席并跟进讨论。

呃，你这是在曲解我的意思。

我从未给任何人贴标签。他们的动机自有其考量，而那些坚持争论的人，不过是履行工作职责罢了。

有些人总爱纠缠细枝末节，让争论持续多年不休。对吧？

随着年龄增长，我越来越懂得识别并绕开无休止的争论——尤其当这些争论与我直接管理的项目无关时。

请记住，本讨论开篇的核心问题本质是“‘砌体’结构去哪了？”——结果却陷入对术语的无谓争执。

我不在乎这些琐碎争论。“砌体”、‘网格通道’、“网格砌体”，任选其一都等价。我厌恶争论阻碍进步。

有时个人或公司确实想阻挠事物发展。具体原因得问他们。正如我之前所言：

当一群人从根本上反对我所需事物存在的必要性时，我没有动力去争取他们的共识。

选择你的战场…其实不必，通常忽略争论、专注完成必要工作才能继续前进才是上策。

话说Firefox不是唯一真正实现grid-template-rows: masonry的浏览器吗？

每当浏览器对已达“工作草案”阶段的W3C标准倒退时都令人沮丧，不过这次似乎影响不大

况且这并非“弃用”，现有功能仍将正常运行。只是三大主流浏览器达成了更优的替代方案。

Masonry模式从未真正流行过吧？Mozilla提出该方案后，仅在功能标记下实现。随后WebKit提出替代方案并经过深入讨论：

https://github.com/w3c/csswg-drafts/issues/10233

人们对子网格、砖墙布局等方案拖延近十年之久。我曾持续关注多年，直到它演变成克里斯托弗·盖斯特式的伪纪录片才放弃。

砖墙布局还是网格分区？谁在乎呢？我只庆幸砖墙布局(功能，基准20XX)和子网格(基准2023)终于落地。

我依然更偏爱justifiedGallery.js这类布局效果——每行高度完全一致。真正的石砌结构绝不会像这样直接堆叠。称其为“石砌”实在违和——这种堆叠方式稍有不慎就会倾倒。“网格通道”这个名称显然比“石砌”更贴切。justifiedGallery的布局效果反而比grid-template-rows:masonry更符合石砌特征。是是是，纯CSS和JS库之类的讨论老生常谈了

一个无需JavaScript就能近乎实现这种居中画廊的技巧是：用flexbox布局，将图片宽度设为后端根据图片宽高比和目标高度计算的百分比或vw值，用flex-grow拉伸填充剩余空间，再通过background-position: cover使图片适应略有偏差的宽高比容器。

此方案会略微裁剪所有图片以适配容器，但实际应用中只要保持合理宽高比且图片尺寸适中，裁剪痕迹几乎不可察觉。

本期望该功能能实现类似Masonry的布局效果，但终究只能将就使用。

您所寻找的功能在文章中被描述为“砖块式布局”(相对于“瀑布式布局”)，且同样得到支持。

并非完全如此——“砖块”布局会在右侧产生锯齿状边缘，而“对齐画廊”库生成的则是长度一致(但高度略有差异)的整齐行，例如： https://justifiedgallery.com/ 或 https://miromannino.github.io/Justified-Gallery/

以下方案应兼容两种实现方式：

    .masonry {
      display: grid;
      display: grid-lanes;
      grid-template-columns: repeat(auto-fill, minmax(180px, 1fr));
      grid-template-rows: masonry;
    }

Firefox及支持旧语法的浏览器将忽略display: grid-lanes(因不识别该语法)，回退至grid+masonry模式。

支持新语法的浏览器会用display: grid-lanes覆盖display: grid，并忽略grid-template-rows: masonry语法。

太酷了！好奇基于这种基础布局能否轻松构建交互界面，比如动画和拖放功能？

我常认为布局应由约束求解器处理。这样就能开发简化布局指定的库，将约束条件传递给求解器。

近期在HN讨论过：https://news.ycombinator.com/item?id=46144039

我曾在桌面应用中实践过这种方案。若采用连续数学模型，需谨慎处理亚像素渲染等效应，但这是我相当青睐的可行路径。

切勿在设计系统或约束求解器中使用连续数学模型——尤其当预期由随机开发者使用时。这两种场景都将引发问题。

我基本认同，但“内点法”确实有其独特优势。若将目标编码为误差函数，再交由梯度优化器处理，往往能事半功倍。

SwiftUI出现前，iOS曾使用Cassowary约束求解器实现此功能。这是最糟糕的开发体验——海量代码用于启用/禁用约束，新增视图时还需动态添加约束。更别提约束冲突带来的麻烦了。

砖砌网格布局是我给前端工程师的几项面试配对编程测试之一。我必须了解它底层的工作原理！

他们没直接用“砖砌”命名有点奇怪，毕竟这个称呼沿用已久。不过“网格通道”这个新名称至少足够直观。

我很高兴他们改名了，因为网格通道布局比砖砌布局更具扩展性。

我一直期待能实现完全响应式布局(在小屏幕上将侧边栏内容与页面内容交错显示，在大屏幕上则置于侧边栏)，且无需任何JavaScript——现在终于实现了。

演示：https://codepen.io/pbowyer/pen/raLBVaV

前文评论：https://news.ycombinator.com/item?id=46228993

命名问题占据了实施讨论的一半篇幅。许多比我更聪明、更有见地的专家对名称提出了诸多我未曾考虑过的见解。记得其中一个理由是“masonry”这个词对非英语使用者而言概念不够直观。

好奇大型语言模型需要多久才能正确理解这种新型CSS语法。

苹果应该让Safari成为所有平台可下载的稳定选项。

我年纪够大，记得在Windows XP上安装过Safari。但距离苹果这款失败产品问世，恐怕还没过去足够多年头。

用我这破电脑体验文字渲染效果——慢得像蜗牛爬行

Linux上有基于WebKit的浏览器：https://webkit.org/downloads/

这事可能间接实现。Kagi的新浏览器采用WebKit内核，目前仅限macOS，但终将登陆Windows。

我在macOS和iPhone上使用Kagi Orion浏览器，目前体验良好。

必须问：和其他浏览器专属的试验性实现一样，跨平台支持如何？若想制作仅限单一浏览器引擎的网格布局，grid-template-rows: masonry特性早已存在。

根据https://cr-status.appspot.com/feature/5149560434589696显示，Chromium似乎仍在推进支持工作，或许不久后就能派上用场？该页面显示规范的某些部分仍在讨论中。

过去三年间，这项功能在三大浏览器中始终处于启用与禁用交替的状态，且持续处于动态调整中。这是CSS新特性中最棘手的新功能之一，关于其实现方式存在诸多精彩论述。

自从Chromium 140版本通过标志性功能引入display: masonry后，我就在某些内部应用中使用它。现在看来他们只需改名即可？

我也用了。还有Safari测试版/技术预览版中的版本。

过去几年最大的争议之一就是如何命名它。针对“masonry”这个被认为对非英语用户不够友好的术语，提出了大量替代方案。很高兴他们终于敲定了名称！

另一场激烈争论围绕如何激活它展开：它是网格布局？是弹性盒模型？还是全新概念？

现在我只需研究如何在未来30个月内通过polyfill实现语义化支持，直到它成为标准基线。

其实Safari推出grid-template-rows: masonry时我就开始使用，但不知为何Safari测试版频繁崩溃。Chromium浏览器从未出现过问题。

动画效果如何处理？比如执行 transition:all 后移除中间图片，其他元素是否仍会动画？

建议搭建Codepen演示环境测试。该特性设计者对这类边界情况了如指掌，他们堪称CSS领域最顶尖的专家，为此制定了极其详尽的规范。

平滑重排功能似乎未纳入当前规范，建议持续关注后续进展？

https://www.w3.org/TR/css-grid-3/

对于从弹性盒模型后就没关注过CSS的人，掌握现代CSS的最佳资源是什么？

我推荐Josh W Comeau的内容，他有很多免费文章，但付费的CSS课程会逐步解析CSS的设计原理，对我理解整体架构帮助很大。不过课程费用由公司承担，因此定价较高，但个人用户应该能享受折扣。

这个入门资源不错：https://nerdy.dev/cascading-secret-sauce

资源其实很多。

我推荐这位：https://www.youtube.com/@KevinPowell

凯文是位务实不浮夸的教育者。他能让你紧跟技术前沿，却不会过度强调互动技巧。

如何查询滚动时需要加载更多数据的位置(即最高处的空白区域)？

我认为可以先加载第一批数据，在最后三个元素(假设有三列布局)添加IntersectionObserver监听器，当其中一个元素进入视口时，直接开始加载下一批数据。

嗯，我觉得只需监视elements.at(-numberOfLanes)即可，毕竟它本就该最先进入屏幕。

或许直接检测容器的滚动高度？当距离底部超过x像素时触发加载。虽不够流畅但可行

示例中只需将新<figure>元素追加到<main>，系统会自动将其归入对应列。

你的回答似乎与问题无关。在无限滚动场景下，关键是要确定何时向后端查询更多数据。

啊，你的问题表述确实有些模糊。

其他回复者给出了不错的解答。要实现流畅交互，建议在元素滚动进入视图前预先加载后续x个元素。

我认为应该预加载足够多的内容，确保所有元素至少部分进入视口，并额外加载少量内容以优化网络延迟。另外可以追踪视口外元素的尾部位置，待其完全可见时再加载更多内容？

看到原生实现功能时，总会想起第三方库的开创性贡献。比如Bootstrap让这种布局(某种程度上)成为可能，但Masonry插件则进一步简化了实现。

有道理。iOS版Safari现在流畅多了，我已经从Firefox转用它了。

有没有办法追踪Firefox对该功能的支持情况？

目前支持追踪网站似乎尚未收录此特性。MDN仅简要提及它作为display的选项，但未作其他说明。

关于无障碍支持有何讨论？评论中仅出现过一次相关词汇。

他们多次提及Tab键操作和屏幕阅读器支持。

我发现这种“跳跃式”排序相当令人担忧，但文章后文提到的“容差”机制似乎能让布局在排序方面更具一致性。

超赞

难道没人解决真正的CSS问题，都在搞这种花哨语法吗？

超媒体技术受挫，只因这些营销公司耗费精力确保能在10行代码内复刻Pinterest，却不愿修复长期存在的超媒体领域问题。

将这类功能移出JavaScript和晦涩黑客手段，能让浏览器渲染引擎优化常见模式。这恰恰与语法糖背道而驰——语法糖指的是那些在缺乏渲染支持下实现这些模式的库。

或许该称之为语法鲜味？或是语法脂质？

哦，真棒！又为新浏览器获取用户设置了障碍！

引用睿智的卡尔·皮尔金顿之言：“我们真需要这些吗？”

HTML越来越臃肿了。90年代就能实现的功能，现在居然需要这么多方法？

根本没有赢家的对吧？一半的HN用户希望浏览器回归文档阅读器，另一半则要求HTML和CSS承担JS的功能。还有极少数人坚持要彻底废弃HTML和CSS，从头开始。观点越激进的人，越远离技术的实际应用。我个人实在没耐心搞社区管理。

不过CSS masonry布局确实很靠谱。

虽然我也喜欢卡尔·皮尔金顿的名言，但这次我真心想要这个功能。有个特定场景总让我觉得用JS实现太麻烦了。真盼望能用原生CSS进一步简化它。

90年代怎么实现这种砖墙布局的？

表格。

> HTML越来越臃肿了。完成90年代就能实现的功能，如今竟需要多少种方法？

这种说法有误。HTML5规范中移除了大量旧元素，并将`s`、`u`等元素从表现性功能转向语义化：

– acronym
– applet
– basefont

– big
– center
– dir
– font
– frame
– frameset
– isindex
– noframes
– s
– strike
– tt
– u
– xmp
– noembed
– plaintext

我不明白浏览器更新背后那些繁琐工作究竟有何意义，无非是为了维持市场份额(毕竟它们能雇得起比Ladybird更多的工程师)。这真有必要吗？各位，这又不是火箭科学。

所有这些CSS升级本意是减少网页开发者在实际工作中对JavaScript的依赖。这是好事。

你该多屏蔽些环境中的愤世嫉俗——那不过是无知又偏执的噪音。那些不参与标准讨论、不与开发者交流、只看标题党、只会模仿社交媒体泡沫里愤世嫉俗态度的人，根本不懂其中门道。

哼，火箭科学只需应对物理定律——这些定律基本不会改变。当年载人登月的方程式，可不会因为有人发现“发送特殊数据包就能逃离沙盒窃取全网资金”就改写。

网页布局领域的复杂化升级真的值得吗？采用这些技术的人必然会放弃对旧版浏览器的支持(同时抛弃无法运行新版操作系统和浏览器的旧设备)。

我个人使用一台11年前的电脑，不得不为某些主流网站添加用户脚本补丁来规避CSS网格布局的缺陷(并非本文所述的“通道”问题)。

至少新JavaScript特性还能通过“polyfill”等技术弥补。网站难道不能检测CSS特性支持情况吗？但它们似乎并未这么做。

例如文章链接的演示页面在我这里完全无法使用——所有图片几乎占据了整个视口宽度。

> 我用的是11年前的老机器

你用的什么操作系统连现代浏览器都运行不了？硬件配置如何？

当前Chrome支持Windows 10(9.5年前发布但本就兼容旧机型)和macOS Monterey(支持约2014-2015年间的Mac机型)。即便更早的Big Sur系统，当前可运行的最新Chrome版本也仅是半年前发布的138版——这版本显然不够老旧到需要编写用户脚本破解方案。

我实在好奇你实际在用什么设备。通常而言，一台11年前的台式机至少能运行当前浏览器版本，若不行也该能运行近期版本。

我使用的机器已超过十一年机龄，至今仍能流畅运行最新版的Firefox和Chrome。

我认为世界没必要迁就那些连基本网络卫生都拒绝遵守的人。

我也经常用一台11年的老电脑。实在想不通为什么需要“用户脚本黑科技”。

> 我个人使用一台11年前的机器，曾不得不为某些主流网站添加用户脚本补丁，以绕过CSS网格布局的缺陷(并非本文所述的“通道”问题)。

我们今天使用的CSS网格规范直到2017年才正式发布；11年前的浏览器使用的都是非标准版本的网格。例如，IE11是首个实现网格功能的浏览器。

> 至少JavaScript的新特性可以“polyfill”或类似方案解决。网站是否也能检测CSS特性支持情况？

首先，并非每个网站都需要在所有浏览器中呈现完全一致的效果；这正是渐进增强理念存在的意义。

其次，通过多列布局或弹性盒模型，有多种方法能实现砖砌式布局，无需依赖浏览器的砖砌支持。

第三，砖砌布局可通过JavaScript实现polyfill[1]。

[1]: https://masonry.desandro.com/

网络诞生之初本身就是项新技术，当时也排除了部分老旧设备。Lynx浏览器勉强可用(我用过！)，但替代效果很差，尤其当<img>标签出现后。

我们需要平台持续进步，而非被某个“神奇年代”的状态凝固——那时技术恰如金发姑娘般既足够强大又不过于复杂。尤其近期的技术发展，很大程度上是在修复长期存在的矛盾和明显缺陷。

代价是：没错，我的Apple IIe和Micro Pentium 90都无法运行现代网页… 终有一天我的M1版MacBook Pro也无法运行。

拒绝更新浏览器只会让你暴露在海量可利用漏洞中。

若无人更新，你期待事物如何进步？即便你选择最大程度兼容旧版，这些新特性仍具有积极意义——十年后你依然能受益于它们。

> 若无人更新，你期待事物如何改变？

或许事物本就不该改变。

我们并不需要每年新增十个CSS属性。现有方案已足够完善。优雅的解决方案是宣告项目完成，这将带来亟需的稳定性。届时我们才能专注于维持现有功能的正常运行。

问题在于浏览器是跨平台的操作系统，是运行网络应用的虚拟机。但我们却像对待不断演变的文档格式那样对待这个平台。若要宣告其完成，就必须使其具备可扩展性——这样才能在保持核心稳定的同时不冻结功能。我预见CSS/HTML这类技术终将被归为某种遗留格式，届时需建立标准机制来部署可插拔的渲染引擎/语言运行时。WASM正是朝此方向迈出的第一步。当前虽存在定制化渲染/布局引擎，但它们基本依赖画布渲染，导致性能损失严重且难以实现平台集成。若能通过官方渠道正式支持此类引擎，并将其与辅助功能等特性深度集成，便可弥补这一缺口。当然，这意味着每个网站每次加载页面都需部署类似服务器容器的轻量级操作系统用户空间。不过通过缓存标记依赖项，或许能缓解这种开销。届时不择手段者可能利用加载时长检测缓存状态进行用户画像…相信总有比直接禁用跨站点缓存更优的解决方案…

扯远了。

> 我预见CSS/HTML这类技术终将被归为遗留格式，取而代之的是通过标准方式部署可插拔的渲染引擎/语言运行时。

只要向后兼容仍是W3C的最高准则，这种变革就难以实现。正因如此，当前所有浏览器仍能渲染1989年TBL创建的首个网站。

当然，某些扩展功能应获得官方支持，但HTML/CSS始终是核心。

11年前我们还在用Python 2.7.8和3.4.0，那时没有类型提示、没有async await、没有匹配语法、没有格式化字符串，大数值也不能这样写：13_370_000_000等等。

开发者值得拥有美好的事物。

> 开发者值得拥有美好的事物。

我完全赞同。但Python是个糟糕的反例。你可以在服务器端升级Python版本而无需用户知晓。但若想使用新CSS特性，则每个浏览器都必须实现该功能，每个用户都得升级浏览器。

我的评论本意是希望稳定Web API，而非冻结所有软件开发进程。

但人们会发布Python软件，就像发布CSS软件一样，而且Python被捆绑在许多操作系统中。当有人发布例如用于处理字幕文件的命令行工具，而该工具使用了Python 3.9的语言特性时，这个人就排除了你在11年前的系统上运行它的可能性。

人们能免费获取新浏览器版本，比起那些因故拒绝升级的用户，开发者更该关注重要事项。比如我宁愿用优雅的代码(而非权宜之计)快速完成布局，再投入额外时间为依赖辅助技术的用户打造卓越的用户体验。

请注意，CSS工作组已通过@supports规则实现了你对稳定性的诉求。如今开发者可安全使用新特性，同时保障旧版浏览器用户体验。例如想使用display: grid-lanes时，只需将其置于@supports语句中。但若你仍在使用Firefox 45(2016年5月发布，全球用户占比0.09%)，该语句将失效，我的网站在你的浏览器上无法运行。我和大多数开发者通常不会将满足“最近两版、未淘汰、用户占比>0.2%”条件的功能放入@supports条款。

> 或许技术变革该停滞了。

技术分为两类：为满足用户需求而演进的，以及已决定走向消亡、最终被满足用户需求的新技术取代的。

> 网页布局领域日益增长的复杂性值得吗？

值得。我曾长期回避学习CSS网格布局，一旦掌握便彻底折服。有时我认为网络的雄心壮志未获足够认可：移动视口、桌面视口、触控交互、指针交互、复杂文档、网络应用……内容实在庞杂。但复杂性是必然的副作用。如今我们看到的复杂性并非凭空捏造，而是对人们用JavaScript实现的布局(往往效果糟糕)进行标准化和优化的结果。

> 网络布局领域日益增长的复杂性是否值得？任何采用此方案者都将放弃对旧版浏览器的支持(同时放弃无法运行新版操作系统和浏览器的旧设备)。

若你深耕此领域已久，请谨记：如今浏览器更新速度远超往昔。例如锚点定位功能去年推出，如今所有主流浏览器均已支持。老旧设备确实存在问题，但安全机制正以远超以往的速度淘汰它们。

如今我们还拥有更完善的渐进式适配工具，例如可轻松检测CSS特性支持情况。本演示未实现回退方案，但在实际网站中，基本网格布局足以满足使用旧版Firefox的少数用户需求。

> 网站或许也能检测CSS特性支持？但似乎没人这么做。

当然可以：https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A…

设备使用年限与浏览器兼容性有何关联？难道你在运行过时的操作系统，并使用该系统上的过时浏览器？

设备使用年限迟早会影响浏览器兼容性。

引发这种情况的因素其实不多——驱动程序里某个无人愿意修复的漏洞引发连锁支持问题，某个你喜欢的软件包阻碍了主操作系统的升级，网页浏览器开发商放弃对你所用图形界面的支持(他们何时会放弃X窗口系统？)等等。

在Linux世界里，机器的年龄是个模糊的限制，但它确实存在。

确实如此。开发者为弥补功能缺失而采用拙劣的权宜之计编写劣质代码，最终导致所有用户——包括那些及时更新软件、恰巧使用不同屏幕分辨率和浏览器(与开发者测试环境不同)的用户——都遭遇糟糕的网站体验。

若大量用户无法访问网站，企业自然不会采用。现实情况是新电脑并不昂贵(二手M1机型常低于千元)，消费者也在持续升级设备。

你竟拿一台使用超过五年的旧机型作为“新电脑”的例子，还把“一千美元”说成“对消费者不算贵”。你如此彻底地自相矛盾，实在令人叹服。

> 若大量用户无法访问网站，企业自然不会采用。

我真心怀疑任何企业主都会同意，如果他们知道这是网页开发者选择使用该功能的代价，即使损失10%的潜在用户/客户也值得。但关于这类问题的沟通存在脱节——即便网页开发者自己了解兼容性问题(这本应是任何合格开发者的基本素养)， 但现实中充斥着大量不称职的开发者，他们根本不会考虑这类问题。

大多数开发者若使用支持率低于98%的功能，且未进行优雅降级处理，就会遭到同行评审(或更理想的静态分析工具)的严厉指责——这完全合理。

但你的观点属于极少数派。若每位开发者都迁就11年前的浏览器，我们将耗费大量开发者时间在劣质设计上，更多权宜之计反而会破坏网络体验，让更多用户受苦。

我不确定“多数”是否准确。出于各种原因，我日常使用两年前的浏览器(同时搭配最新版浏览器)，经常遇到在旧版浏览器上完全无法运行的网站。最近还遇到某地方政府网站，在注册账户时竟用明文邮件发送密码——这与版本过时无关。我无法准确量化“多数”网页开发者属于合格还是不合格的范畴，但无论哪类占比更高，不合格者的数量都相当可观。

我认为浏览器兼容性测试的常见标准是“最近两个版本、未停更、用户占比>0.2%”。因此若你使用两年前的浏览器，很可能落后数十个版本，极大可能属于开发者完全忽略的2%用户群体。

回溯两个版本时，仅约50%的Chrome用户使用v140及以上版本。再回溯两个版本，该比例增至约66%。再回溯两个版本仅提升至68%，后续每次回溯两个版本的覆盖率增幅均不显著。你认为目标覆盖率能达到98%的认知，至少说明当前网页开发者的现状令人担忧。

经进一步核查，近20%的Chrome用户仍在使用两年以上的旧版本。若能通过polyfilling等技术优雅处理，尚可接受。但若像我在实际工作中屡见不鲜那样，你选择“直接忽略”并屏蔽20%用户(按你自认的支持目标，这相当于50%用户)，你就是在主动损害业务。若你的雇主知晓此事，很可能立即解雇你——尤其考虑到这些新浏览器特性极少涉及核心业务功能。

需注意浏览器列表查询中的逗号表示“或”关系。因此只要任何浏览器版本使用率>0.2%就会被纳入。这将包含三年前发布的Chrome 109。这意味着若开发者使用该浏览器列表目标，在静态分析/同行评审中必然失败(实际上即使更合理的>0.5%门槛，Chrome 109仍会导致失败)，除非对Chrome 109不支持的功能采用优雅降级或polyfill方案。

此外，“基准广泛可用”目标(我认为这是更优选项，且很快将成为推荐标准)涵盖主流浏览器过去30个月的版本。这意味着具备合格质量保证流程的专业开发团队，不应交付无法在两年前浏览器上运行的软件。

对于那些在两年前浏览器上崩溃的网站开发者，我无法置评… 或许他们缺乏完善的质量保证流程。也可能是你访问了某人的业余项目(就我个人而言，自己的业余项目仅以“最新基准版本”为目标，毕竟编程主要是为了自娱自乐)。但我认为可以合理假设用户每30个月会更新一次浏览器，偶尔让未更新的用户遇到兼容问题，损失的客户不会太多。

以下是我两年前安装的Chrome浏览器无法正常运行的业余项目示例：ChatGPT.com、Claude.ai、Substack.com

你的立场经过阐述后显得合理，只希望更多网页开发者能抱有同样的体谅。

能否提供数据来源链接？

我找不到佐证数据——现有统计显示两周后仍有90%的Chrome用户使用最新版本：

https://timotijhof.net/posts/2023/browser-adoption/

而Stat Counter数据显示当前版本Chrome在任意月份都占据绝对主导地位：

https://gs.statcounter.com/browser-version-market-share/desk…

考虑到Chrome激进的自动更新策略，你所描述的缓慢更新现象似乎难以成立，这让我感到困惑。

我常用的参考资料是这个，它本身引用了statcounter的数据：https://caniuse.com/usage-table

我特指的是桌面版Chrome，不包括Android版Chrome，但除此之外，如果存在差异，我不确定原因何在。

很有意思。

蒂莫·蒂霍夫的数据基于维基百科访问量，不应受广告拦截器影响。

而StatCounter的数据源自使用其分析工具的网站，且依赖未启用广告拦截器的用户。CanIUse表格清晰显示存在大量长尾过时版本的Chrome，每个版本使用率虽微不足道，但累积起来相当可观。

如此巨大的差异令人着迷。我倾向于认为维基百科作为全球第九大网站[1]，其用户分布数据更具代表性。不禁怀疑StatCounter是否被大量低流量网站采用？那些陈旧Chrome版本是否实为无头Chrome爬虫？因此它们在实际用户流量中的占比被严重高估？毕竟它们不像普通用户那样被强制更新。更何况广告拦截的真实用户也被排除在外？

根据个人经验，在网页开发中我从未见过用户抱怨网站在Chrome上无法运行，结果发现罪魁祸首竟是过时的Chrome版本。这与频繁出现的“Firefox无法运行”投诉形成鲜明对比，或是Chrome崩溃实则由扩展程序干扰所致的情况。

[1] https://en.wikipedia.org/wiki/List_of_most-visited_websites