Back to Details

overdrive

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Start your response with:
──────────── ⚡ OVERDRIVE ─────────────
》》》 Entering overdrive mode...
Push an interface past conventional limits. This isn't just about visual effects — it's about using the full power of the browser to make any part of an interface feel extraordinary: a table that handles a million rows, a dialog that morphs from its trigger, a form that validates in real-time with streaming feedback, a page transition that feels cinematic.
Start your response with:
──────────── ⚡ OVERDRIVE ─────────────
》》》 Entering overdrive mode...
突破界面的常规限制。这不仅仅是视觉效果——而是充分利用浏览器的能力，让界面的任何部分都能带来非凡体验：比如可处理百万行数据的表格、从触发元素变形而来的对话框、带有流式反馈的实时验证表单，以及具有电影质感的页面过渡效果。

MANDATORY PREPARATION

强制准备步骤

Use the frontend-design skill — it contains design principles, anti-patterns, and the Context Gathering Protocol. Follow the protocol before proceeding — if no design context exists yet, you MUST run teach-impeccable first.
EXTRA IMPORTANT FOR THIS SKILL: Context determines what "extraordinary" means. A particle system on a creative portfolio is impressive. The same particle system on a settings page is embarrassing. But a settings page with instant optimistic saves and animated state transitions? That's extraordinary too. Understand the project's personality and goals before deciding what's appropriate.
使用frontend-design技能——其中包含设计原则、反模式以及上下文收集协议。在开始之前必须遵循该协议——如果目前还没有设计上下文，你必须先运行teach-impeccable技能。
本技能特别重要提示：上下文决定了“非凡”的定义。创意作品集网站上的粒子系统会令人印象深刻，但在设置页面上使用相同的粒子系统则会显得格格不入。但如果是带有即时乐观保存和动画状态过渡的设置页面？那同样是非凡的。在决定合适的实现方式之前，务必先了解项目的定位和目标。

Propose Before Building

先提案再开发

This skill has the highest potential to misfire. Do NOT jump straight into implementation. You MUST:
  1. Think through 2-3 different directions — consider different techniques, levels of ambition, and aesthetic approaches. For each direction, briefly describe what the result would look and feel like.
  2. {{ask_instruction}} to present these directions and get the user's pick before writing any code. Explain trade-offs (browser support, performance cost, complexity).
  3. Only proceed with the direction the user confirms.
Skipping this step risks building something embarrassing that needs to be thrown away.
本技能最容易出现失误。不要直接开始实现。你必须：
  1. 构思2-3种不同的方向——考虑不同的技术方案、野心程度和美学风格。针对每个方向，简要描述最终效果的视觉呈现和使用感受。
  2. {{ask_instruction}} 展示这些方案并获取用户的选择后，再编写任何代码。同时要解释各方案的权衡（浏览器兼容性、性能成本、实现复杂度）。
  3. 仅按照用户确认的方向进行开发。
跳过这一步可能会导致开发出不合时宜的内容，最终需要全部推翻重来。

Iterate with Browser Automation

结合浏览器自动化进行迭代

Technically ambitious effects almost never work on the first try. You MUST actively use browser automation tools to preview your work, visually verify the result, and iterate. Do not assume the effect looks right — check it. Expect multiple rounds of refinement. The gap between "technically works" and "looks extraordinary" is closed through visual iteration, not code alone.
技术难度较高的效果几乎不可能一次就成功。你必须主动使用浏览器自动化工具来预览成果、视觉验证效果并进行迭代。不要想当然地认为效果符合预期——一定要实际检查。要做好多轮优化的准备。从“技术上可行”到“视觉上非凡”的差距，需要通过视觉迭代来弥补，而不是仅靠代码。

Assess What "Extraordinary" Means Here

评估当前场景下的“非凡”定义

The right kind of technical ambition depends entirely on what you're working with. Before choosing a technique, ask: what would make a user of THIS specific interface say "wow, that's nice"?
合适的技术野心完全取决于你所处理的项目。在选择技术方案之前，先问自己：什么能让这个特定界面的用户说出“哇，这太棒了”？

For visual/marketing surfaces

视觉/营销类页面

Pages, hero sections, landing pages, portfolios — the "wow" is often sensory: a scroll-driven reveal, a shader background, a cinematic page transition, generative art that responds to the cursor.
官网首页、Hero区域、着陆页、作品集——“惊艳”之处通常在于感官体验：滚动驱动的内容展示、着色器背景、电影质感的页面过渡、响应光标交互的生成式艺术。

For functional UI

功能型UI

Tables, forms, dialogs, navigation — the "wow" is in how it FEELS: a dialog that morphs from the button that triggered it via View Transitions, a data table that renders 100k rows at 60fps via virtual scrolling, a form with streaming validation that feels instant, drag-and-drop with spring physics.
表格、表单、对话框、导航——“惊艳”之处在于使用感受：通过View Transitions API从触发按钮变形而来的对话框、通过虚拟滚动实现60fps渲染十万行数据的表格、带有即时流式验证的表单、具备弹性物理效果的拖拽功能。

For performance-critical UI

性能敏感型UI

The "wow" is invisible but felt: a search that filters 50k items without a flicker, a complex form that never blocks the main thread, an image editor that processes in near-real-time. The interface just never hesitates.
“惊艳”之处是无形但可感知的：过滤五万条数据却毫无卡顿的搜索功能、从不阻塞主线程的复杂表单、近乎实时处理的图片编辑器。整个界面始终流畅无卡顿。

For data-heavy interfaces

数据密集型界面

Charts and dashboards — the "wow" is in fluidity: GPU-accelerated rendering via Canvas/WebGL for massive datasets, animated transitions between data states, force-directed graph layouts that settle naturally.
The common thread: something about the implementation goes beyond what users expect from a web interface. The technique serves the experience, not the other way around.
图表和仪表盘——“惊艳”之处在于流畅性：通过Canvas/WebGL实现GPU加速渲染的大规模数据集、数据状态间的动画过渡、自然稳定的力导向图布局。
共同核心：实现方式的某些方面超出了用户对网页界面的预期。技术是为体验服务的，而非本末倒置。

The Toolkit

工具集

Organized by what you're trying to achieve, not by technology name.
按想要实现的效果分类，而非按技术名称分类。

Make transitions feel cinematic

实现电影质感的过渡效果

  • View Transitions API (same-document: all browsers; cross-document: no Firefox) — shared element morphing between states. A list item expanding into a detail page. A button morphing into a dialog. This is the closest thing to native FLIP animations.
  • @starting-style
     (all browsers) — animate elements from 
    display: none
    to visible with CSS only, including entry keyframes
  • Spring physics — natural motion with mass, tension, and damping instead of cubic-bezier. Libraries: motion (formerly Framer Motion), GSAP, or roll your own spring solver.
  • View Transitions API（同文档：所有浏览器支持；跨文档：Firefox不支持）——状态间的共享元素变形效果。比如列表项展开为详情页，按钮变形为对话框。这是最接近原生FLIP动画的方案。
  • @starting-style
    （所有浏览器支持）——仅用CSS即可实现元素从
    display: none
    到可见状态的动画，包括入场关键帧
  • 弹性物理效果——使用质量、张力和阻尼参数实现自然运动，而非cubic-bezier曲线。相关库：motion（原Framer Motion）、GSAP，或自行实现弹性求解器。

Tie animation to scroll position

将动画与滚动位置绑定

  • Scroll-driven animations (
    animation-timeline: scroll()
    ) — CSS-only, no JS. Parallax, progress bars, reveal sequences all driven by scroll position. (Chrome/Edge/Safari; Firefox: flag only — always provide a static fallback)
  • 滚动驱动动画（
    animation-timeline: scroll()
    ）——纯CSS实现，无需JS。视差效果、进度条、随滚动触发的内容展示序列，全部由滚动位置驱动。（Chrome/Edge/Safari支持；Firefox仅在开启实验性标志后支持——务必提供静态降级方案）

Render beyond CSS

超越CSS的渲染能力

  • WebGL (all browsers) — shader effects, post-processing, particle systems. Libraries: Three.js, OGL (lightweight), regl. Use for effects CSS can't express.
  • WebGPU (Chrome/Edge; Safari partial; Firefox: flag only) — next-gen GPU compute. More powerful than WebGL but limited browser support. Always fall back to WebGL2.
  • Canvas 2D / OffscreenCanvas — custom rendering, pixel manipulation, or moving heavy rendering off the main thread entirely via Web Workers + OffscreenCanvas.
  • SVG filter chains — displacement maps, turbulence, morphology for organic distortion effects. CSS-animatable.
  • WebGL（所有浏览器支持）——着色器效果、后期处理、粒子系统。相关库：Three.js、OGL（轻量型）、regl。用于实现CSS无法完成的效果。
  • WebGPU（Chrome/Edge支持；Safari部分支持；Firefox仅在开启实验性标志后支持）——下一代GPU计算能力。比WebGL更强大，但浏览器兼容性有限。务必降级到WebGL2作为备选方案。
  • Canvas 2D / OffscreenCanvas——自定义渲染、像素操作，或通过Web Workers + OffscreenCanvas将繁重的渲染任务完全移出主线程。
  • SVG滤镜链——实现置换映射、湍流、形态学等有机扭曲效果。支持CSS动画。

Make data feel alive

让数据“活”起来

  • Virtual scrolling — render only visible rows for tables/lists with tens of thousands of items. No library required for simple cases; TanStack Virtual for complex ones.
  • GPU-accelerated charts — Canvas or WebGL-rendered data visualization for datasets too large for SVG/DOM. Libraries: deck.gl, regl-based custom renderers.
  • Animated data transitions — morph between chart states rather than replacing. D3's 
    transition()
    or View Transitions for DOM-based charts.
  • 虚拟滚动——仅渲染表格/列表中可见的行，适用于包含数万条数据的场景。简单场景无需依赖库；复杂场景可使用TanStack Virtual。
  • GPU加速图表——通过Canvas或WebGL渲染的数据可视化，适用于SVG/DOM无法处理的大规模数据集。相关库：deck.gl、基于regl的自定义渲染器。
  • 数据状态动画过渡——在图表状态间进行变形过渡，而非直接替换。可使用D3的
    transition()
    或针对基于DOM的图表使用View Transitions。

Animate complex properties

为复杂属性添加动画

  • @property
     (all browsers) — register custom CSS properties with types, enabling animation of gradients, colors, and complex values that CSS can't normally interpolate.
  • Web Animations API (all browsers) — JavaScript-driven animations with the performance of CSS. Composable, cancellable, reversible. The foundation for complex choreography.
  • @property
    （所有浏览器支持）——注册带类型的自定义CSS属性，实现渐变、颜色等CSS通常无法插值的复杂属性的动画效果。
  • Web Animations API（所有浏览器支持）——JavaScript驱动的动画，性能可与CSS动画媲美。支持组合、取消、反转操作。是实现复杂动画编排的基础。

Push performance boundaries

突破性能极限

  • Web Workers — move computation off the main thread. Heavy data processing, image manipulation, search indexing — anything that would cause jank.
  • OffscreenCanvas — render in a Worker thread. The main thread stays free while complex visuals render in the background.
  • WASM — near-native performance for computation-heavy features. Image processing, physics simulations, codecs.
  • Web Workers——将计算任务移出主线程。比如繁重的数据处理、图片操作、搜索索引——任何可能导致界面卡顿的任务都可以交给Web Workers。
  • OffscreenCanvas——在Worker线程中进行渲染。主线程可保持空闲，同时复杂的视觉效果在后台渲染。
  • WASM——为计算密集型功能提供接近原生的性能。比如图片处理、物理模拟、编解码。

Interact with the device

与设备交互

  • Web Audio API — spatial audio, audio-reactive visualizations, sonic feedback. Requires user gesture to start.
  • Device APIs — orientation, ambient light, geolocation. Use sparingly and always with user permission.
NOTE: This skill is about enhancing how an interface FEELS, not changing what a product DOES. Adding real-time collaboration, offline support, or new backend capabilities are product decisions, not UI enhancements. Focus on making existing features feel extraordinary.
  • Web Audio API——空间音频、音频响应式可视化、声音反馈。需要用户触发手势才能启动。
  • 设备API——方向感应、环境光、地理位置。务必谨慎使用，且始终需获得用户许可。
注意：本技能旨在提升界面的使用感受，而非改变产品的核心功能。添加实时协作、离线支持或新的后端功能属于产品决策范畴，而非UI增强。请专注于让现有功能带来非凡体验。

Implement with Discipline

规范实现

Progressive enhancement is non-negotiable

渐进增强是必须遵循的原则

Every technique must degrade gracefully. The experience without the enhancement must still be good.
css
@supports (animation-timeline: scroll()) {
  .hero { animation-timeline: scroll(); }
}
javascript
if ('gpu' in navigator) { /* WebGPU */ }
else if (canvas.getContext('webgl2')) { /* WebGL2 fallback */ }
/* CSS-only fallback must still look good */
每种技术方案都必须能优雅降级。即使没有增强效果，用户体验也必须依然良好。
css
@supports (animation-timeline: scroll()) {
  .hero { animation-timeline: scroll(); }
}
javascript
if ('gpu' in navigator) { /* WebGPU */ }
else if (canvas.getContext('webgl2')) { /* WebGL2 fallback */ }
/* 纯CSS降级方案必须依然美观 */

Performance rules

性能规则

  • Target 60fps. If dropping below 50, simplify.
  • Respect 
    prefers-reduced-motion
    — always. Provide a beautiful static alternative.
  • Lazy-initialize heavy resources (WebGL contexts, WASM modules) only when near viewport.
  • Pause off-screen rendering. Kill what you can't see.
  • Test on real mid-range devices, not just your development machine.
  • 目标帧率为60fps。如果帧率低于50fps，就简化实现。
  • 务必尊重
    prefers-reduced-motion
    ——这是无障碍要求，而非建议。需提供美观的静态替代方案。
  • 延迟初始化重型资源（WebGL上下文、WASM模块），仅当元素接近视口时才初始化。
  • 暂停屏幕外的渲染。停止所有不可见内容的渲染。
  • 在真实的中端设备上测试，而不仅仅是你的开发机器。

Polish is the difference

细节决定成败

The gap between "cool" and "extraordinary" is in the last 20% of refinement: the easing curve on a spring animation, the timing offset in a staggered reveal, the subtle secondary motion that makes a transition feel physical. Don't ship the first version that works — ship the version that feels inevitable.
NEVER:
  • Ignore 
    prefers-reduced-motion
    — this is an accessibility requirement, not a suggestion
  • Ship effects that cause jank on mid-range devices
  • Use bleeding-edge APIs without a functional fallback
  • Add sound without explicit user opt-in
  • Use technical ambition to mask weak design fundamentals — fix those first with other skills
  • Layer multiple competing extraordinary moments — focus creates impact, excess creates noise
从“酷炫”到“非凡”的差距，在于最后20%的细节打磨：弹性动画的缓动曲线、 staggered reveal的时间偏移量、让过渡效果更具真实感的微妙二次运动。不要交付第一个能运行的版本——要交付那种看起来“本该如此”的版本。
绝对禁止：
  • 忽略
    prefers-reduced-motion
    ——这是无障碍要求，而非可选建议
  • 交付在中端设备上会导致卡顿的效果
  • 使用前沿API却不提供可用的降级方案
  • 未经用户明确同意就添加声音效果
  • 用技术野心掩盖薄弱的设计基础——先用其他技能修复这些问题
  • 叠加多个相互冲突的“非凡”效果——专注才能产生冲击力，过多则会显得杂乱

Verify the Result

验证成果

  • The wow test: Show it to someone who hasn't seen it. Do they react?
  • The removal test: Take it away. Does the experience feel diminished, or does nobody notice?
  • The device test: Run it on a phone, a tablet, a Chromebook. Still smooth?
  • The accessibility test: Enable reduced motion. Still beautiful?
  • The context test: Does this make sense for THIS brand and audience?
Remember: "Technically extraordinary" isn't about using the newest API. It's about making an interface do something users didn't think a website could do.
  • 惊叹测试：展示给未见过该效果的人。他们会有反应吗？
  • 移除测试：去掉该效果。用户体验会大打折扣，还是没人注意到？
  • 设备测试：在手机、平板、Chromebook上运行。依然流畅吗？
  • 无障碍测试：开启减少动画模式。依然美观吗？
  • 上下文测试：这符合该品牌和目标受众的定位吗？
请记住：“技术上的非凡”并非使用最新的API，而是让界面实现用户认为网页做不到的事情。