说实话，Ru果你还以为 CSS 只是那个用来改改背景颜色、调调字间距的“样式表”，那你可Neng真的要被时代抛弃了。圈子里流传着一个老梗：前端工程师这一辈子，似乎dou在跟那个该死的 标签Zuo斗争。为了让它长得稍微符合人类审美，我们不得不引入 Chosen、Select2，或者是 React Select……结果呢？仅仅为了一个下拉框，项目里硬生生塞进了几百 KB 的 JavaScript 代码。

这听起来是不是hen荒谬？但这就是我们曾经不得不面对的现实。然而现在的风向变了而且变得非常快。今天我想聊聊几个让人眼前一亮的 CSS 新特性，它们不仅仅是语法的geng新，geng是对设计工作流的颠覆。你可Neng会惊讶地发现，那些曾经需要开发人员熬夜写逻辑才Neng实现的效果，现在可Neng只需要几行样式代码就Neng搞定。

滚动驱动动画：告别 JS 监听的卡顿时代

以前，当我们想要实现一个随着页面滚动而变化的进度条，或者是那种高大上的视差滚动效果，通常是怎么Zuo的？没错，我们得依赖 JavaScript。我们需要去监听 scroll 事件，然后在回调函数里用 requestAnimationFrame 去计算每一帧的位置。这不仅写起来头疼，geng重要的是它往往是性Neng杀手。一旦主线程稍微忙一点，页面滚动就会出现掉帧，用户体验大打折扣。

但现在CSS 原生支持了动画进度绑定滚动位置。这意味着什么？意味着你Ke以把动画的进度直接交给浏览器的渲染引擎去处理，完全不经过 JavaScript 的主线程。性Neng？那是丝般顺滑。

来kan个Zui简单的例子，一个阅读进度条：

#progress {
  height: 4px;
  background: #0066cc;
  /* 动画进度绑定滚动位置 */
  animation: grow-progress linear forwards;
  animation-timeline: scroll;
}
@keyframes grow-progress {
  from { width: 0%; }
  to { width: 100%; }
}

这就完了？是的，这就完了。不需要监听，不需要计算，浏览器知道你想干什么。Ru果你觉得这还不够震撼，那来kankangeng高级的视差效果。以前想Zuo那种图片随滚动缩放、淡入淡出的效果，代码量Neng写满一屏幕。现在呢？

.parallax-image {
  /* 滚动时图片从 1 倍缩放到 1.5 倍 */
  animation: scale-image linear forwards;
  animation-timeline: scroll;
  animation-range: entry 25% exit 75%;
}
@keyframes scale-image {
  from { transform: scale; opacity: 0; }
  to { transform: scale; opacity: 1; }
}

这简直是魔法。设计师们kan到这里估计要惊呼了：“所以之前Zuo的那个滚动交互动效，现在不用等开发排期了？” 确实hen多以前需要切图、写逻辑的交互，现在 CSS 自己就Neng扛下来。

智Neng色彩对比：自动适配背景色

这绝对是设计师的福音。我想大家肯定dou遇到过这种让人抓狂的场景：设计师给了一个按钮，背景色是动态的——可Neng来自用户的个性化设置，也可Neng来自后端的数据。问题随之而来：当背景色hen深的时候，文字必须是白色；当背景色hen浅的时候，文字得变成黑色，否则根本kan不清。

以前怎么Zuo？老老实实用 JS 写个函数去计算颜色的亮度，然后动态地给元素加个 class。这过程繁琐不说还容易出错。现在呢？CSS 给我们带来了 contrast-color 函数。

.button {
  --bg-color: #0066cc; /* Ke以是任何颜色 */
  background-color: var;
  /* 自动选择黑色或白色，保证可读性 */
  color: contrast-color);
}

甚至，你还Ke以指定候选色列表，让函数帮你挑一个对比度Zui高的：

.button {
  /* 指定两个候选色，让函数选择对比度geng高的那个 */
  color: contrast-color, vs-black, #fff, #eee);
}

这意味着什么？这意味着设计系统里的文本颜色，以后Ke以自动适配背景了！你再也不用为了每一个可Neng的背景色去手动定义文字颜色了。这不仅仅是省事，geng是为了保证 WCAG 可访问性标准。设计师惊呼：“所以以后设计系统里的文本颜色，Ke以自动适配背景了？” 没错，就是这么智Neng。

Sticky 导航栏的阴影：终于不用 JS 监听了

再来聊聊一个经典的痛点。以前我们想给 sticky 导航栏加个阴影，怎么Zuo？流程简直让人崩溃：监听 scroll 事件，计算滚动距离，判断元素是否“粘住”……一堆性Neng杀手代码写下来只为了加那一点点阴影。

现在有了 scroll-state 这个 API，一切变得异常简单。我们Ke以直接检测元素是否处于“粘住”的状态。

.sticky-nav {
  container-type: scroll-state;
  position: sticky;
  top: 0;
}
.sticky-nav> nav {
  transition: box-shadow 0.3s;
  /* 只有当元素真正"粘住"时才加阴影 */
  @container scroll-state {
    box-shadow: 0 4px 20px rgba;
  }
}

这行代码的意思非常直白：当导航栏粘在顶部的时候，给它加个阴影。不需要 JS 去计算像素，也不需要去判断 offset。设计师们终于不用跟开发解释“当导航栏粘住时加阴影”是什么意思了代码本身就是Zui好的注释。

原生 Select 标签的救赎

文章开头提到了那个关于 select 标签的笑话。现在原生 select 终于Ke以随便改了。以前为了自定义下拉框，我们不得不隐藏原生的 select，然后用一堆 div 和 span 去模拟，还要处理键盘导航、无障碍访问等一堆麻烦事。

现在通过 appearance: base-select，我们Ke以开启可自定义模式，甚至Ke以在选项里放图片！

/* 开启可自定义模式 */
select, ::picker {
  appearance: base-select;
}
/* 选项里甚至Ke以放图片 */
option {
  display: flex;
  align-items: center;
  gap: 8px;
}
option img {
  width: 24px;
  height: 24px;
  border-radius: 50%;
}

对应的 HTML 结构也变得非常语义化：

👇 张三 李四

这是什么概念？这意味着以后 Figma 里的下拉框设计，douNeng 1:1 还原了！不用再为了几百 KB 的库文件纠结，也不用担心模拟出来的组件在移动端表现不佳。设计师惊呼：“所以以后 Figma 里的下拉框设计，douNeng 1:1 还原了？” 答案是肯定的。

 {
  /* 默认状态 */
  opacity: 0;
  transform: scale;
  transition: opacity 0.3s, transform 0.3s;
}
:popover-open {
  /* 打开后的状态 */
  opacity: 1;
  transform: scale;
}
/* 定义"开始动画前的状态" */
@starting-style {
  :popover-open {
    opacity: 0;
    transform: scale;
  }
}