Windows 滚动条快捷方式简史
Windows 滚动条行为，尤其是像 Shift+点击这样可直接跳到某个位置的快捷方式，暴露出许多现代应用和框架已经偏离一致、原生 UI 控件这一事实。评论者将经典的 Win32 和 Cocoa 小部件与当今大量自定义和 Electron 风格界面进行对比，前者因速度、可预测性和可访问性受到称赞，后者则常常忽视系统规范、主题和键盘习惯。这个讨论串也凸显了人们对隐藏功能、细窄或消失的滚动条，以及以品牌为导向的设计选择的广泛不满——这些选择更重视视觉新奇，而不是可用性和肌肉记忆。
滚动条点击行为与快捷方式
- 围绕在滚动条轨道空白处左键点击应该做什么展开了争论：
- 在 Windows 上，许多应用会将其视为向上/向下翻页。
- 也有人提到某些应用会在单击时直接跳到对应位置（“scroll here”），不过另一些人测试常见的 Windows 11 应用后并没有看到这种行为。
- Shift+点击实现“scroll here”被强调为一个强大但不为人知的快捷方式；有些人用它来判断某个应用是否使用真正的 Win32 滚动条。
- 对于“scroll here”应当作为默认的轨道空白处操作，还是翻页，以及误触导致意外跳转是否是严重问题，存在分歧。
- 过去那种通过把拖动移到滚动条很远处来取消拖拽的行为，据说在当前 Windows 版本中表现并不一致。
跨平台差异
- Linux/GTK 通常默认在轨道空白处使用点击即跳转（“scroll here”）；修饰键点击（Shift、中键、右键）因应用而异（Firefox、LibreOffice、Inkscape、Qt 应用）。
- macOS 提供了一个全局偏好设置，可在“点击滚动条时跳到下一页”与“跳到点击位置”之间切换；有些用户会避开不理会该设置的应用。
- 这些差异被用来说明为什么不应在 Web UI 中重做滚动条，因为要匹配每个平台的规范都很困难。
自定义滚动条与原生工具包
- 许多人感叹很少有应用使用原生 Win32 滚动条，将原因归咎于框架和自定义主题。
- 抱怨包括缺少标准行为（如滚动条右键菜单或 Shift+点击）、性能更差、可访问性更差，以及键盘快捷方式不一致。
- 有人认为原生控件（Win32、Cocoa、GTK）“足够好”，并倾向于一致性而不是品牌化。
UI 一致性、主题与品牌
- 对 Windows 自 Windows 8 以来在不同框架之间日益严重的 UI 不一致感到强烈不满。
- 由品牌驱动的自定义 UI（例如忽略强调色和活动窗口提示的 Office 应用）被认为损害了可用性。
- 在视觉独特性与遵循系统主题、快捷方式和用户偏好之间存在张力。
网页上的细窄/隐藏滚动条
- 许多人不喜欢超细或自动隐藏的滚动条，因为这会让滚动更困难，并掩盖文档长度。
- 有人指出，macOS 默认隐藏滚动条导致网页设计者忽视溢出问题，从而在其他平台上造成“滚动条乱象”。
- 建议包括通过浏览器配置调整来恢复完整、高对比度的滚动条。
Windows 桌面应用的框架选择
- 开发者表示不确定现在该用什么（WinForms、WPF、Electron、Qt、基于 Rust 的技术栈、纯 Win32）。
- 原生工具包因响应速度而受到赞扬；网页/桌面混合方案（如 Electron）则被批评为臃肿且迟缓。
- 网格/表格控件和高 DPI 支持是反复出现的痛点，常常迫使人们转向第三方组件。
隐藏行为与可发现性
- 几位参与者最近才发现像 Shift+点击或滚动条上下文菜单这样的快捷方式。
- 有人呼吁建立这些“隐藏”的标准行为目录，以便重实现时至少可以尽量做到一致。