2026，原生 CSS 正在吃掉 JavaScript 的活儿

一、引言：一场悄无声息的范式转移

如果你在 2026 年启动一个新项目，遇到的第一个问题可能不是"选 React 还是 Vue"，而是——

这个功能，浏览器现在能不能原生实现？

过去十年，前端开发者养成了一套肌肉记忆：遇到交互需求，先搜 NPM 包。Tooltip → Popper.js。瀑布流 → Masonry.js。滚动动画 → GSAP/ScrollTrigger。状态管理 → Redux/Zustand。

但在 2026 年，这套肌肉记忆正在失效。

不是因为这些库不好，而是因为浏览器厂商在过去三年里，以前所未有的节奏推进了 CSS 新特性的标准化和落地。CSS 从一个"描述样式的语言"进化为一个具有作用域、条件逻辑、动画系统和布局引擎的完整声明式编程语言。

本文不只是一个新特性清单，而是想探讨一个更深层的问题：当浏览器原生能力足够强时，前端开发的职责边界在哪里？

二、Anchor Positioning：浮层定位的终局方案

过去：一个 Tooltip 要多少代码？

回想一下你要实现一个 Tooltip 的流程：

1. 获取触发元素的 DOM 位置（getBoundingClientRect）
2. 计算 Tooltip 应该出现在哪个方向
3. 检查是否会溢出视口，如果是则换方向
4. 监听滚动和窗口大小变化重新定位
5. 处理边界情况（嵌套滚动容器、transform 影响等）

这就是 Popper.js 存在的理由——它用几千行 JS 封装了以上所有逻辑。类似地，Floating UI、Tippy.js 都是围绕这个痛点建立的三方生态。

现在：5 行 CSS 搞定

2026 年，CSS Anchor Positioning 规范已经进入稳定阶段。

/* 第一步：定义锚点 */
.trigger-button {
  anchor-name: --tooltip-anchor;
}

/* 第二步：引用锚点定位 */
.tooltip {
  position: absolute;
  position-anchor: --tooltip-anchor;
  bottom: anchor(--tooltip-anchor top);
  left: anchor(--tooltip-anchor left);
}

边界碰撞自动处理：

.tooltip {
  position-try-options: flip-block, flip-inline, flip-block flip-inline;
}

position-try-options 是真正的杀手级特性。它告诉浏览器：如果当前方向放不下，就自动尝试镜像翻转、轴向翻转，直到找到一个不会溢出视口的位置。这在过去需要几十行条件判断。

更复杂的场景：锚点组合定位

.popover {
  position: absolute;
  position-anchor: --button-ref;
  top: anchor(--button-ref bottom);
  left: anchor(--button-ref center);
  translate: -50% 8px;
  position-try-options: flip-block, --bottom-align-left;
}

/* 自定义备选方案 */
@position-try --bottom-align-left {
  top: anchor(--button-ref bottom);
  left: anchor(--button-ref left);
  translate: 0 8px;
}

浏览器实现现状

• Chrome 120+ — 完整支持（2023年底）
• Safari 17.2+ — 完整支持
• Firefox — 正在实现中
• Interop 2026 — 跨浏览器一致性目标

实际影响

Popper.js 的 npm 周下载量在 2023 年达到峰值（约 1800 万/周），2025-2026 年开始出现下滑。不是因为开发者不再需要 Tooltip，而是因为新建项目中，越来越多的团队选择"先看浏览器能不能搞定"。

三、Scroll-driven Animations：从监听滚动到声明动画

过去：滚动动画为什么这么难？

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const progress = entry.intersectionRatio;
      entry.target.style.opacity = progress;
      entry.target.style.transform = `translateY(${40 - 40 * progress}px)`;
    }
  });
}, { threshold: Array.from({ length: 101 }, (_, i) => i / 100) });

上面这段代码的问题：

1. 主线程执行 — 回调跑在主线程上，遇到长任务会造成动画卡顿
2. 精度有限 — threshold 数组只能离散取值，无法做到真正的 60fps 连续动画
3. 逻辑分散 — 滚动监听、状态计算、样式更新分散在三处，难以维护
4. 与框架冲突 — React 的批处理机制和直接操作 DOM 的动画往往产生冲突

这就是为什么 GSAP 的 ScrollTrigger 插件能成为行业标准——它用复杂的底层优化解决了这些问题。

现在：CSS 层面的原生解决方案

Scroll Progress Timeline（滚动进度）

关联到滚动容器的滚动进度。页面滚动了 0% → 动画 0%，滚动了 50% → 动画 50%。

@keyframes shrink-header {
  from { height: 80px; font-size: 1.5rem; }
  to { height: 50px; font-size: 1rem; }
}

.site-header {
  position: sticky;
  top: 0;
  animation: shrink-header linear both;
  animation-timeline: scroll(root block);
  animation-range: 0 200px;
}

View Progress Timeline（视口进度）

关联到元素本身进入/离开视口的进度。

@keyframes slide-in {
  from { opacity: 0; transform: translateX(-100px); }
  to { opacity: 1; transform: translateX(0); }
}

.article-card {
  animation: slide-in linear both;
  animation-timeline: view(block);
  animation-range: entry 0% entry 100%;
}

animation-range 的精细控制：

animation-range 可以取四种模式：

• entry — 元素进入视口的过程
• exit — 元素离开视口的过程
• contain — 元素完全在视口中的过程
• cover — 从元素开始进入到最后完全离开

你可以组合使用：

.element {
  animation: fade-in-out linear both;
  animation-timeline: view(block);
  animation-range: entry 0% entry 100%, exit 0% exit 100%;
}

真实案例

根据 Chrome 团队的案例分享，一家东南亚电商平台用 scroll-driven animations 替换了原有的 JS 滚动动画实现后：

• 主线程阻塞时间：从 120ms 降至 0ms（动画完全在合成器线程执行）
• 滚动卡顿率：从 3.2% 降至 0.4%
• 代码量：从 80 行 JS + 滚动监听 → 15 行 CSS

浏览器支持

• Chrome 115+ ✅ / Safari 17.5+ ✅
• Firefox 尚未实现（这是 2026 年最大的遗憾点）

四、CSS Grid Lanes (Masonry)：十几年老坑终于被填平

回溯：为什么 Masonry 布局一直这么难？

Pinterest 在 2011 年带火了瀑布流布局。此后十余年，前端开发者用各种 hack 来模拟它：

• CSS Columns — 元素按列排列，但顺序是自上而下，不是从左到右
• Flexbox — 只能单行或单列，无法自动填隙
• Grid — 可以定义行列，但所有行高相同，无法实现瀑布效果
• JS 计算 — 每个元素加载后计算其高度，找到最短列插入

Masonry.js 的作者 David DeSandro 在 2021 年就表示："如果浏览器能原生支持瀑布流，这个库就可以退休了。"

现在的最终方案

CSS 工作组经过多年辩论，最终确定了现在的方案：

.gallery {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
  grid-template-rows: masonry;  /* 核心：这一行触发瀑布流 */
  gap: 16px;
}

没错，仅仅是在 Grid 布局上加一行声明。

进阶配置：

.gallery {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  grid-template-rows: masonry;
  gap: 16px;  
  align-tracks: start;
  justify-tracks: stretch;
}

跨越多个格子：

.item-featured {
  grid-column: span 2;
  grid-row: span 2;
}

渐进增强写法

由于浏览器支持还没全覆盖，推荐渐进增强：

.gallery {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
  gap: 20px;
  columns: 3;
  column-gap: 20px;
}

@supports (grid-template-rows: masonry) {
  .gallery {
    grid-template-rows: masonry;
    columns: unset;
  }
}

实际意义

在 2026 年之前实现瀑布流，你需要安装 Masonry.js、所有图片必须在渲染前知道高度、处理动态加载时的重新计算、处理断点变化。CSS Grid Lanes 让这一切归零——零 JS 依赖，浏览器自动处理。

五、Container Queries：组件真正的"独立宣言"

从页面级响应式到组件级响应式

Container Queries 在 2023 年就已可用，但 2026 年它有了更多组合能力。

在 Container Queries 之前，"响应式"等于"页面级响应式"——你只能在 viewport 层面做断点判断。但一个组件放在侧边栏和放在主内容区，它的实际宽度完全不同。用 @media query 无法感知这一点。

.card-wrapper {
  container-type: inline-size;
  container-name: card;
}

@container card (width < 400px) {
  .card { flex-direction: column; }
}

@container card (width >= 400px) and (width < 700px) {
  .card { flex-direction: row; }
  .card-image { width: 200px; }
}

@container card (width >= 700px) {
  .card { flex-direction: row; }
  .card-image { width: 300px; }
  .card-details { display: block; }
}

六、@scope：真正的 CSS 作用域

CSS 的作用域问题被大家用各种方式绕了十几年：BEM（人肉维护）、CSS Modules（构建时依赖）、Shadow DOM（副作用多）、Styled Components（运行时开销）。@scope 是第一个零代价的原生方案。

@scope (.media-card) {
  :scope {
    display: flex;
    gap: 16px;
    border-radius: 8px;
  }

  > h3 { font-size: 1.125rem; }
  img { border-radius: 4px; }
}

/* 带上下限的 scope */
@scope (.card) to (.card-footer) {
  p { line-height: 1.6; }
}

七、2026 年 CSS 新特性全景

八、对前端开发者的影响

NPM 生态的结构性变化

这不是猜测，而是正在发生的事实。Popper.js 月下载量在 2023 年达到峰值后，2025-2026 年开始下滑。同样的趋势正在影响 Masonry.js、ScrollMagic、GSAP ScrollTrigger 等库。不是因为没人需要这些功能了，而是增量项目中选择 CSS 原生方案的团队越来越多。

性能提升是"免费的"

这些 CSS 特性最吸引人的地方是：性能提升不需要写额外代码。合成器线程执行意味着不阻塞主线程，零 JS 运行时意味着更小的包体积，GPU 加速意味着流畅的 60fps 体验。对比 JS 实现：监听 scroll → RAF → 计算状态 → 修改样式（触发回流/重绘），CSS 方案直接将动画指令交给合成器线程，跳过所有中间环节。

学习路径的转移

2026 年的前端学习路线正在发生变化：过去是 HTML + CSS 基础 → JS 精通 → 框架 → NPM 包解决问题；现在是 HTML → 现代 CSS（容器查询、Grid、锚点定位、动画） → JS → 少量精选包。CSS 的复杂度在增加，但回报也在增加。

实用的决策框架

面对一个新功能需求，推荐的决策流程：首先查 CSS 能否实现，然后考虑 CSS + JS polyfill 渐进增强，最后才考虑上库。这个流程倒过来就是过去十年的做法。2026 年，顺序应该反过来了。

九、总结

2026 年的 CSS 已经不是"美工语言"了。它正在成为一个具有作用域系统、条件逻辑引擎、完整动画框架和多轴布局引擎的声明式编程语言。它在 Web 平台的能力图谱上持续向右扩展，吃掉的不是 JavaScript 本身，而是 JavaScript 作为"胶水层"去补足浏览器能力不足的那部分工作。

"能用 CSS 解决的问题，就不要用 JavaScript"——这句话在 2026 年比以往任何时候都更正确。