按钮与链接的区别

# 按钮与链接的区别 来源：https://unplannedobsolescence.com/blog/buttons-vs-links/ ## 计划外过时 (https://unplannedobsolescence.com/) - 首页 (https://unplannedobsolescence.com/) - 博客 (https://unplannedobsolescence.com/blog) - 演讲 (https://unplannedobsolescence.com/talks) - 关于 (https://unplannedobsolescence.com/about) - RSS (https://unplannedobsolescence.com/atom.xml) --- 2026年7月28日 在Triptych项目 (https://triptychproject.org/) 的三项提案中——这是我为HTML添加几个小而强大功能所经历的多年旅程——引发最多疑问的是按钮操作 (https://triptychproject.org/proposals/button-actions)。该提案本身非常直接：我们希望在按钮上添加`action`和`method`属性。 ```html <button action="/submit" method="POST">开始</button> ``` 按钮操作（Button Actions）是如此简单的原始概念，以至于人们常常问为什么需要它们。答案基于一个用户直觉理解但很少直接思考的区别：按钮与链接的区别。我在提案中添加了详细的“按钮与链接”(https://triptychproject.org/proposals/button-actions#buttons-vs-links) 部分，但我觉得也有必要用博客形式解释一下，因为大多数现有的解释都偏离了重点。 ## 按钮具有固定上下文 (https://unplannedobsolescence.com/blog/buttons-vs-links/#buttons-have-a-fixed-context) 链接代表一个目的地 (https://www.w3.org/WAI/ARIA/apg/patterns/link/)，而按钮代表一个动作 (https://www.w3.org/WAI/ARIA/apg/patterns/button/)。从功能上讲，这意味着链接允许用户控制它们打开的上下文，而按钮则不行。 Web浏览器为重新设置链接的上下文提供了无数便利。点击或轻触链接会导航当前页面到该目的地。鼠标用户可以中键点击链接以在新标签页中打开，或者悬停在链接上查看其指向。上下文菜单（桌面端右键点击，移动端长按）包含许多链接特定的选项。 Web用户非常熟悉链接附带的功能。他们知道如何打开、复制、收藏、与朋友分享链接，以及在数量多得离谱的浏览器标签页中维护它们。链接的语义——即它们代表一个可独立导航的目的地——使得浏览器能够构建所有这些功能。超链接的发明早于浏览器标签页，但当浏览器增加标签页时，网站无需做任何支持工作；链接代表可以重新设置上下文的目的地，因此浏览器可以简单地发明一个新上下文让它们在其中打开。每个网站都立即获得了一项巨大的新功能升级。 按钮则不具备这些功能。默认情况下，它们不能中键点击、Ctrl+点击或悬停查看更多信息。按钮不允许像复制链接的`href`那样复制其`action`。它们的上下文菜单中没有保存动作或将其另作他用的选项。这些并非疏漏，而是基于按钮语义的刻意选择：按钮在特定浏览上下文（几乎总是当前上下文 (https://triptychproject.org/proposals/button-actions#ref-15)）内触发动作。复制、分享、收藏——这些都是重新设置链接动作上下文的特性。按钮服务于互补的目的，因为它们**不**允许任何此类操作。 ## 按钮何时应该导航？ (https://unplannedobsolescence.com/blog/buttons-vs-links/#when-should-buttons-navigate) 一个常见的误解是，链接用于页面导航，而按钮用于其他所有事情。这种说法两方面都是错误的。按钮经常执行导航操作。点击“注销”按钮会将当前页面导航到已注销状态的页面；点击“搜索”按钮会将当前页面导航到查询结果页面。而链接也常用于**不**触发导航的情况。相对链接可以跳转到当前页面内的位置；mailto链接可以打开邮件客户端；下载链接可以将文件保存到本地。这些都不是导航，但它们都是可以以可定制方式打开、保存和分享的“目的地”。 当导航操作发生在固定且无法重新设置上下文（例如收藏、分享、中键点击等）的上下文中时，导航应以按钮形式呈现。一个常见场景是编辑已保存内容的表单，比如网站上的评论。当您点击“编辑”时，网站会显示一个可编辑的文本区域，并提供如下选项： ```html <form> <textarea>我今天过得很棒！</textarea> <button type="submit">保存</button> <button>保存草稿</button> <button>取消</button> <button>删除</button> </form> ``` 用户很容易理解每个按钮的作用： - “保存”用`<textarea>`中的内容更新评论 - “保存草稿”保存`<textarea>`的内容但不发布 - “取消”关闭可编辑表单 - “删除”完全移除评论 “取消”应该是一个链接吗？不！它的任务是关闭编辑视图。将其做成链接不仅在视觉和其他方面错误地传达了其目的，还会给它带来许多不正确的功能，比如收藏和中键点击。这些按钮的实现方式有很多种，但没有任何一种实现应该向用户呈现为链接。 ## 按钮操作弥补了什么缺口？ (https://unplannedobsolescence.com/blog/buttons-vs-links/#what-gap-do-button-actions-fill) 有了按钮操作（Button Actions），整个用户体验只需HTML即可实现。 ```html <form> <textarea>我今天过得很棒！</textarea> <button type="submit">保存</button> <button>保存草稿</button> <button action="/view/1" method="GET">取消</button> <button action="/delete/1" method="DELETE">删除</button> </form> ``` 前两个按钮使用了现有的HTML特性，后两个按钮则通过Button Actions实现。（我还利用了Triptych的DELETE支持 (https://triptychproject.org/proposals/form-http-methods)，但您也可以使用URL方法技巧 (https://triptychproject.org/proposals/form-http-methods#ad-hoc-uri-semantics) 而不依赖它。） ```html <button action="/view/1" method="GET">取消</button> <button action="/delete/1" method="DELETE">删除</button> ``` 从哲学上讲，Button Actions创建了一个通用控件，可以通过网络请求重新绘制当前上下文。按钮已经具备此能力，但有一定限制；该提案移除了这些限制。 实际上，这允许Web作者通过导航到视图来实现状态转换。这些视图可能已经作为独立目的地存在，在这种情况下，作者可以轻松重用现有路由，同时在UI中正确表示动作。这是一个很好的模式，HTML应该鼓励！ 不幸的是，没有Button Actions，错误地将这个按钮做成链接是我们不用脚本就能实现此界面的唯一方式。 ```html <form action="/update/1" method="POST"> <textarea>我今天过得很棒！</textarea> <button type="submit">保存</button> <button>保存草稿</button> <a href="/view/1" class="usa-button">取消</a> <a href="/delete/1" class="usa-button">删除</a> </form> ``` 这显然是一个反模式，但它被主流设计系统所支持，因为按钮无法在没有表单的情况下进行基本导航。在构建无需JavaScript即可运行的网站（例如英国政府网站的要求 (https://design-system.service.gov.uk/accessibility/accessibility-strategy/#progressive-enhancement)）时，链接是唯一的选择。 美国网页设计系统（USWDS）甚至为此提供了官方便利 (https://designsystem.digital.gov/components/button/)：向链接添加`class="usa-button"`，它就会看起来像按钮。然而，让链接看起来像按钮，并不会让链接的行为像按钮。USWDS使用JavaScript (https://github.com/uswds/uswds/pull/4385) 来实现空格键激活，但JavaScript无法解决区分按钮和链接的诸多其他行为 (https://triptychproject.org/proposals/button-actions#link-button-accessibility)，比如上下文菜单。链接（即使带有`role=button` (https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/button_role)）在阅读模式或其他自定义视图中仍然会显示为链接。这是违反HTML语义的基本后果——页面会对某些用户造成问题，因为作者不可能考虑到人们与网页交互的所有不同方式。如果作者必须考虑所有情况，网页根本无法正常工作。 导航是Web作者控制用户体验最广泛的工具——HTML只需要完善`<button>`触发导航的能力。这样做将使Web对所有用户更简单、更安全、更易访问。 *如果您想支持这项工作，最好的方式是点赞GitHub上的Button Actions议题 (https://github.com/whatwg/html/issues/12330)，并分享该提案对您有价值的实例。* ## 注释 (https://unplannedobsolescence.com/blog/buttons-vs-links/#notes) - 特别感谢Django软件基金会 (https://www.djangoproject.com/foundation/) 对这项提案的支持 (https://www.djangoproject.com/weblog/2026/jul/15/supporting-the-triptych-project/)！ - 我正在撰写一份分析报告，以证明Button Actions不会给现有网站引入任何新的XSS漏洞。支持该提案并不能解决那个问题，但它确实向WHATWG表明Web作者有此需求，且值得研究。 - 这篇博客重点讨论了无需表单即可触发GET请求的按钮，因为这是与链接重叠的部分，但触发不安全请求而无需表单的按钮也非常有用。`DELETE`请求可能是最常见的用例，因为它们通常不需要额外数据。 - 按钮在没有表单的情况下触发`POST`或`PUT`请求的一个有趣案例是社交网站的“点赞” (https://triptychproject.org/proposals/button-actions#likes-and-upvotes)。例如，HackerNews (https://news.ycombinator.com/) 使用链接进行点赞，这严重违反了HTTP语义。但我理解他们这样做的原因：更简单且无需JavaScript。这就是为什么不仅要让Button Actions可行，还要让它便捷。 - 该提案解决了所有现有的解决此功能缺失的变通方案 (https://triptychproject.org/proposals/button-actions#existing-workarounds)，并解释了它们为何不够充分。 - Triptych的总体目标是为Web作者提供一种简单且语义化的方式，在HTML中建模完整的CRUD生命周期 (https://en.wikipedia.org/wiki/Create,_read,_update_and_delete)，因为绝大多数Web服务所需要做的也就是这些。 - 所有Triptych提案相辅相成——Button Actions在配合其他方法 (https://triptychproject.org/proposals/form-http-methods) 和部分页面替换 (https://triptychproject.org/proposals/partial-page-replacement) 时更加有用——但我尽量单独为每个提案阐述理由，既作为反捆绑机制，也因为它们各自确实很有用。