过去几年，主要浏览器厂商（谷歌（Google）、苹果（Apple）、微软（Microsoft）和 Mozilla，以及 Igalia 和 Bocoup）在合作推进 Interop 项目，以改善网页技术的跨浏览器支持。这一合作成效显著：重点领域加入 Interop 后，往往一年内就能在所有主要浏览器中接近 100% 支持。CSS 子网格（CSS Subgrid）就是好例子，它是 CSS 网格（CSS Grid）的强大扩展，能实现全新布局，2019 年在火狐（Firefox）实现，但其他浏览器多年进展不大，直到被列入 Interop 2023，年底便在所有现代浏览器中广泛可用。

过去几年里，所有主流浏览器厂商（Google、Apple、Microsoft 和 Mozilla，以及 Igalia 和 Bocoup）一直在共同推进 Interop 项目，目标是提升 Web 技术在所有浏览器中的统一支持。这一努力成效显著：某个重点领域一旦被纳入 Interop，往往在一年内就能在各大浏览器中实现接近 100% 的支持。✨

CSS Subgrid 就是一个很好的例子。Subgrid 是 CSS Grid 的一个超强扩展，能实现全新的布局。它在 2019 年就在 Firefox 中实现了，但其他浏览器多年来没有动静。它后来被纳入 Interop 2023，到那年年底，已在所有现代浏览器中广泛可用：

Y 轴表示各浏览器中与 subgrid 相关的测试通过百分比，黑色“Interop”线表示在所有浏览器中都通过的测试。

随着 2026 年接近尾声，Interop 2027 正在规划中，Mozilla 团队创建了一个排名系统，供我们为最期待的功能投票。他们计划根据排名数据决定明年 Interop 收录哪些功能！在这篇博客中，我想深入介绍我投票支持的前 10 个功能，让大家提前看看未来一年内 CSS 可能的发展。文中也会有一些现在就能用的小技巧！

1. CSS 函数

当前浏览器支持情况：Chrome 155 和 Edge 154 已支持；Firefox 157 不支持；Safari 27 不支持。

最令人兴奋的提案之一是为 CSS 添加函数。我们可以用 @function 定义函数，并用 result 指定返回值。例如，定义 @function --gradient-to-transparent(--color, --direction: bottom)，使其返回 linear-gradient(to var(--direction), var(--color), transparent)；随后通过 background: --gradient-to-transparent(red); 调用它，最终生成 background: linear-gradient(to bottom, red, transparent);。

如果你熟悉 JavaScript，会觉得这很熟悉：我们用 @function 定义新函数，用 result 指定返回值。有了它，能做的事非常多。我个人最感兴趣的用例是在极坐标和笛卡尔坐标之间转换，这也是我在 Whimsical Animations 课程中反复使用的概念。例如，定义 @function --translate-polar(--angle, --distance)，返回 translate(calc(cos(var(--angle)) * var(--distance)), calc(sin(var(--angle)) * var(--distance)))；然后对 .particle 使用 transform: --translate-polar(45deg, 100px);，就能把元素沿 45° 方向移动 100px。这对我来说相当有“科幻感”，但它已经在 Chromium 浏览器中实现。如果它能被纳入 Interop 2027，我很可能会很快在各大浏览器中广泛可用！

2. 用 corner-shape 实现 bevel 与 squircle

在 CSS 中，我们可以用 border-radius 属性把 DOM 节点的边缘磨圆，创建圆角矩形。这个属性实际上是在每个角添加一个四分之一圆，把 4 条直边连接起来。而 corner-shape 属性则在探索连接 DOM 节点 4 条边的替代方式，它提供了一系列新选项：

刚听到这个属性时，我最兴奋的是 squircle。如果你不熟悉，squircle 是一种用超椭圆生成圆角的替代算法，能产生更平滑、更柔和的边缘，苹果已经用了很多年。不过在把玩 corner-shape 一段时间后，我发现自己大量使用 corner-shape: bevel。它非常适合做电子游戏或科幻风格的 UI。下面是我正在做的一个副项目的预览，里面用了大量的 corner-shape: bevel：

严格来说，我们之前用 clip-path 或遮罩也能实现类似效果，但与这些功能不同，corner-shape 会真正改变 border-box 的形状。这意味着边框、outline 和 box-shadow 都会正确贴合改变后的角形状！尽管在撰写本文时（2026 年 10 月）该属性尚未在 Firefox/Safari 中可用，但我认为现在就开始使用它也是合理的，它是一个完美的渐进增强特性！

3. 用 border-shape 实现无限可能

除了 corner-shape，还有一个单独的 border-shape 提案，它本质上是一个更底层的版本，允许我们自己绘制边框。我在最近一期的 newsletter 中深入探讨了 border-shape 这个属性，这里不再重复太多。简而言之，border-shape 让我们可以用直线、圆弧和贝塞尔曲线画出任意想要的边框形状。我最近用这个属性画了一张顶部带大圆形缺口的卡片：

与 corner-shape 一样，这个属性会改变元素实际的 border box，因此边框、outline 和阴影都会正确描摹它。我画出想要的形状，再添加白色边框和黑色 outline，就实现了上图的效果！我们甚至可以在不同边框形状之间制作动画，就像我在视频里做的那样。

4. 锚定容器查询

我最近发布了一篇关于 Anchor Positioning 的博客文章，这是最令人兴奋的现代 CSS 特性之一（它其实已被 Interop 2026 优先推进，现在已广泛可用！）。Anchor Positioning API 允许我们把一个元素锚定到另一个元素上。例如，可以把浮动提示框（tooltip）锚定到触发它的按钮上，这样无论按钮在页面何处，提示框都会始终连着它。

如果你自己尝试解决过这类问题，就知道它非常棘手。比如，我们可能希望提示框浮在锚点上方，但如果锚点靠近视口顶部怎么办？提示框可能舒适显示，也可能被截断。最初的 Anchor Positioning API 已经提供了用 CSS 轻松解决此问题所需的大部分工具：它允许我们指定兜底位置；如果目标元素在上方放不下，就会自动翻转到下方。唯一缺失的是判断目标是否已翻转的能力。在 CSS 中，我们无法知道目标元素当前是在锚点上方还是下方，用的是默认位置还是兜底位置。对提示框来说这是个问题，因为我们通常想加一个小凸起指向锚点。Anchor Positioning API 的“Level 2”版本引入了一种新型容器查询，让我们可以检查目标元素是否正在使用兜底位置。你可以在我的 Anchor Positioning 博客文章中了解更多，或查看 Interop 2027 提案。

5. CSS inherit() 函数

说实话，我此前从未听说过这个提案，而且据我所知，它尚未在任何浏览器中实现。它甚至没有被 caniuse 收录，所以我没法展示那些小部件！然而，我一看到它，就觉得非拥有不可。😂

你可能知道，CSS 中的 inherit 关键字允许我们把值从父元素传递下来，即使该属性通常不会被继承。这是个复用值的小技巧，但我经常发现它并不完全好用。例如，假设有嵌套的圆角（border radii）：为了让嵌套圆角看起来正确，我们需要减小内层的圆角半径。所以我并不想直接使用继承来的值，而是想对它进行变换。这时，提案中的 inherit() 函数就派上用场了。它会取出继承的值，并允许我们用 calc() 修改它，例如 p { border-radius: calc(inherit() - 4px); }。考虑到这个功能还非常初步，如果它能入选 Interop 2027，我会有点惊讶。但我希望未来真能拥有这个功能，它看起来超级有用。😄

在我的 scroll-driven animations 博客文章中，我们探讨了如何通过滚动来擦除（scrub）关键帧动画。例如，可以让元素在进入视口时逐渐淡入。Scroll-driven animations 是 Interop 2026 的一部分，现已成功在所有浏览器中实现。然而，除了 scroll-driven 动画，还有一个单独的 scroll-triggered 动画提案。scroll-triggered 动画的目标是在用户滚动到特定点时触发关键帧动画，就像接近传感器被触发一样；之后动画会在指定时长内正常运行。目前我们可以用 JavaScript 的 IntersectionObserver API 实现 scroll-triggered 动画，但这挺麻烦的。等我们能同时用 CSS 处理 scroll-driven 和 scroll-triggered 动画时，一定会非常棒，因为它们各有适用场景。关于 scroll-triggered 动画，你可以在 Bramus 的这篇精彩文章中了解更多。

7. CSS reading-flow 与 reading-order

我目前正在做一个涉及动态网格布局的项目。项目在桌面端和移动端的排列方式非常不同：

桌面端布局

移动端布局

这是响应式 CSS 的一大优势，但也带来一个不幸的副作用：Tab 键顺序始终基于 DOM 顺序，而非视觉顺序。因此，如果有人使用辅助技术在元素间导航，无论布局随屏幕尺寸发生多大变化，导航顺序始终不变。在桌面端，视觉上的第一个项目是左侧的那列内容；但在移动端，第一个项目是那个大红按钮。DOM 中最先出现的元素会最先获得焦点，这对一部分用户来说总是错的。

幸好，新的 reading-flow 属性为我们提供了解决方案，并且已有 Interop 2027 提案。基本思路是，我们可以指定 Tab 顺序遵循几种视觉顺序之一，例如 .grid { display: grid; reading-flow: grid-rows; }。它为 CSS Grid 和 Flexbox 都提供了对应值；如果需要更多控制，reading-order 属性允许我们创建自定义顺序，有点类似 HTML 中的 tabIndex。这个属性由我个人非常崇拜的 Rachel Andrew 推动，你可以在她关于 reading-flow 的博客文章中了解更多。

8. 用 interpolate-size 和 calc-size() 实现关键字尺寸动画

Web 领域长期以来的一个痛点是无法在 auto 等关键字值之间制作动画。interpolate-size 属性解决了这个问题，并且已有相关的 Interop 2027 提案，同时还有配套的 calc-size() 函数。这个功能最常见的用例是在 height: 0 和 height: auto 之间制作动画，用于创建可折叠的手风琴式 UI。你的浏览器目前尚不支持 interpolate-size 属性，下面是它在受支持浏览器中的效果。

诚然，这个例子有点复杂，还需要用到 transition-behavior 等其他小众但支持良好的 CSS。关键在于，interpolate-size: allow-keywords 让这类过渡成为可能。这个提案已经存在一段时间了，且自 2024 年起就在 Chrome 中实现，所以希望它能入选 Interop 2027！尽管尚未在所有浏览器可用，我们现在就可以将其作为渐进增强来使用。只要确保把 transition 放在 @supports 查询里，否则不受支持的浏览器会出现短暂延迟。

9. CSS 间隙装饰

CSS Grid 布局的独特之处在于，网格子项完全由 CSS 定义的行/列来定位。而在其他所有布局模式中，元素都是通过其他元素来定位的！例如在表格布局中，每个网格单元格都有对应的 td 或 th 元素。CSS Grid 有很多优点，但缺点之一是不太容易在网格单元格之间添加边框。如果某个网格单元格是空的，就没有元素可以加 border: 1px solid！

gap decorations 提案引入了一组新的 CSS 属性，让我们可以在网格本身上使用类似边框的语法。请看下面：你的浏览器目前尚不支持 rule 属性，下面是它在受支持浏览器中的效果：

与 border 一样，rule 属性是一个简写属性，允许我们指定线条的宽度、颜色和样式（dashed/dotted/solid）。如果只想在每行或每列之间画线，也可以使用 row-rule 和 column-rule。

在使用 position: sticky 时，你是否曾希望知道元素当前是否处于“粘住”状态？例如，当粘性头部粘在视口顶部时，改变它的背景色。这个提案旨在实现一种新型容器查询，当 position: sticky 元素从正常文档流位置切换为锚定到视口时，该查询就会匹配。请看示例：如果你的浏览器尚不支持这个功能，下面是它的效果。

有趣的是，这个新 API 不只用于粘性定位；我们可以用它查询各种与滚动相关的状态。例如，我们可以判断滚动容器是否滚动到了顶部/底部，这对显示那些指示滚动的渐变很有用：如果还能向上滚动，scrollable: top 就会匹配，从而显示悬浮在内容顶部的伪元素；当完全滚到顶部时，scrollable: top 不再适用，渐变也就隐藏了。下面是它在受支持浏览器中的效果。

结语

随着 Interop 进入第 7 个年头，它无疑为 Web 取得了巨大成功。最后，我强烈建议你也为自己最期待的功能投票排名！这份清单里有很多很棒的提案，包括一些令人兴奋的 JavaScript API（比如 Temporal），只是它们不太适合放进这篇关于 CSS 的博客文章中。

围绕一篇展望 CSS 新特性的文章，社区在“现代 CSS 是否真的变好了”上明显分裂：一方享受原生 HTML/CSS 与变量、打印媒体查询、函数等新能力，另一方则认为新特性（尤其函数）让 CSS 更像 JavaScript、更复杂，继承和层叠等旧问题并未解决。还有人吐槽所谓“浏览器共同努力”实则多为 Chrome 独占预览，老文件的摇树优化难题也依旧无人问津。

享受现代 CSS 与原生方案带来的乐趣

• 不少人自称属于“喜欢 CSS”的少数派，认为 CSS Modules、变量调色板、暗色模式切换、打印媒体查询等已让日常开发很好用；有人用纯 HTML 加 CSS 生成报表，屏幕上显示交互图表，打印时切换成静态 SVG，还能方便 AI 读取。（较多人）
• 坚持尽量写原生 HTML/CSS/JS 的人表示，脱离框架后更能体会这些标准的进步，直言“让人愉快”。（较多人） > CSS 一直很符合我的直觉，也很敬佩那些推动可能要 5 到 10 年才普及的改进的人。（@CharlesW）

认为新特性让 CSS 更复杂、更像 JavaScript

• 有人质疑是否真的需要 CSS 函数：既然 CSS 早已图灵完备，与其继续在样式表里做“杂技”，不如更好地和 JavaScript 集成。（较多人）
• 也有评论担心这些提议让 CSS 变得没必要地复杂，尤其函数会让它越来越像 JS；有人提醒 inherit() 和函数会像文档标记里的 transclusion、条件逻辑一样打开一堆麻烦。（较多人） > 既然 CSS 早就图灵完备，与其继续加函数做这些杂技，不如更好地和 JavaScript 集成。（@lioeters）

认为继承与层叠等旧疾未除，宁可用 Tailwind

• 有批评者把热衷现代 CSS 的人比作只谈现代 C++ 多好、却无视旧问题仍在的人：如果不能从 CSS 里移除继承和层叠，就没什么好谈的，目前仍会选择 Tailwind。（少数人） > 除非把继承和层叠从 CSS 里去掉，否则没什么好谈的，我现在还是用 Tailwind。（@slopinthebag）

质疑所谓浏览器合作实为 Chrome 独占预览

• 有人觉得文章开头称赞各家浏览器携手合作有点讽刺，因为列出的特性几乎全都是 Chrome 独占，更像是未来预览而非今天可用的标准。（少数人） > 前面还在称赞浏览器合作，结果提到的每个特性都只有 Chrome 支持，像是给潜在未来做的预览。（@herpdyderp）

抱怨 CSS 仍无法摇树优化、旧文件膨胀成怪物

• 有开发者吐槽至今仍不能对 CSS 做摇树优化，老旧样式表因此越长越庞大，感觉整个社区已经放弃解决这个问题。（少数人） > 到现在还是不能对 CSS 做摇树优化，老样式文件越长越恐怖，感觉大家都已经放弃了。（@jamienk）

对锚点定位、响应式 iframe 与自动圆角等具体特性期待

• 有人看好 Anchor Positioning，觉得它不像函数或继承那样带着大量历史包袱；也有人兴奋于响应式尺寸 iframe 标准，认为能超越老式 frameset，把 iframe 当积木来拼网站；还有人希望内置相对圆角，免去“外圆角 = 内圆角 + 内边距”的手动计算。（少数人） > 响应式 iframe 终于超越老式 frameset，能把网站当成积木来拼，而不必借助 Web Components。（@koolala）

有价值的补充

• 有人联想到十四年前一段在初代树莓派上用 Qt5 与 QML 实时编码的演示： > 那像是把 CSS 和 JavaScript 混在一起写简单着色器，仿佛另一条时间线里能看到的 CSS 未来。（@watersb）
• 一条带点玩笑的社区情绪： > HTML 和 CSS 就像 bash，如果不是因为到处都是、没得选，根本不会有人用。（@asdfsa32）