用途
该技能针对界面布局中的“滚动区域”（Scroll Areas）问题，提供一套设计约束与审查清单。其核心主张是：默认避免在页面内部创建滚动容器（如面板、抽屉、表格、带内部溢出的模态框），因为内部滚动会带来使用摩擦——用户必须先发现某个区域可以滚动，还要同时管理多个独立的滚动位置，并在同一屏幕的多个滚动区域之间切换上下文。
默认做法是让页面滚动。单一的页面级滚动是普遍理解的，不需要用户去发现。在引入内部滚动区域之前，应先考虑能否重构布局，让页面本身处理溢出。
内部滚动的替代方案
资料给出的替代方案包括：
- 对长列表使用分页或“加载更多”
- 对长详情面板使用可折叠区块（手风琴）
- 将原本会填满滚动区域的内容放到单独页面或路由
- 渐进式披露——默认少显示，按需展开
何时内部滚动是合理的
资料指出，某些布局确实需要内部滚动：
- 固定高度的侧边栏，其导航树长于视口
- 数据表格，需要在行滚动时保持表头可见
- 聊天或日志面板，其流是连续的，而周围布局是固定的
- 嵌入在更大应用外壳中的代码编辑器或终端窗格
在这些情况下可以继续，但需应用下述约束。
只允许一个轴
绝不要创建同时在两个轴上滚动的滚动容器。双轴滚动会让人迷失方向，难以精确控制，在触屏设备上几乎不可用。
/* One axis: vertical */
overflow-y: auto;
overflow-x: hidden;
/* One axis: horizontal (e.g. wide table) */
overflow-x: auto;
overflow-y: hidden;
/* Never */
overflow: auto; /* allows both axes */
如果内容需要两个轴——例如受限面板内的宽表格——应重构布局，使表格的水平滚动成为视图中唯一的滚动，此时页面本身不滚动。
始终由用户控制
滚动绝不能在无用户意图的情况下自动发生。具体包括：
- 不得在用户未发起的情况下自动滚动并移动视口
- 不得劫持滚动——不要拦截原生滚动事件来人为地动画或控制节奏
- 仅在恢复先前滚动位置时（例如离开后返回列表），加载时滚动到某位置才是可接受的
- 作为对用户操作的响应（提交带错误的表单、点击目录链接），滚动到错误或锚点是可接受的
例外：聊天和日志面板在新内容出现时可以自动滚动到底部，但仅当用户已经在底部时。如果用户已向上滚动阅读，不要强制将其拉回底部——而应显示“新消息”指示。
滚动提示
用户必须能够在尝试滚动之前判断某个区域可以滚动。
- 在边缘视觉上裁剪内容——部分可见的条目暗示“还有更多”
- 使用细微的滚动条（不要用
scrollbar-width: none），使轨道可见 - 在触屏上，边缘的部分条目是主要提示——确保容器在尾部边缘没有
overflow: hidden
审查清单
- 每个内部滚动区域是否真的必要，或者能否重构布局以使用页面滚动？
- 每个滚动容器是否只在一个轴上滚动？
- 所有滚动容器是否都避免了
overflow: auto（双轴）？ - 滚动是否始终由用户发起——没有劫持，没有强制自动滚动？
- 可滚动区域是否视觉上明显（部分内容、可见滚动条）？
- 在触屏设备上，滚动是否平滑且原生（
-webkit-overflow-scrolling: touch或等效方案）？