You’ve clicked a button that unexpectedly navigated you away, and you felt that jolt of confusion. That’s not a bug. That’s a broken mental model.
For decades, the web had a simple, sacred contract: links take you somewhere, buttons do something. That distinction is the bedrock of accessible, predictable user interfaces. It’s what lets blind users know that a <button> will trigger an action (like submitting a form) while a <a href> will change the page. It’s what lets power users tab through a page and know exactly what each element will do.
But now, a proposal is circulating to add action and method attributes to buttons. The idea is to let buttons navigate to a URL, essentially turning them into links that can also submit data. On the surface, it sounds convenient—one less element to choose from. But dig deeper, and you’ll find a dangerous erosion of the web’s semantic foundation.
The web is not an app runtime. It’s a hypertext document system. Forgetting that leads to chaos.
This isn’t a technical debate about HTML attributes. It’s a war between two competing paradigms: the web as a document system versus the web as a full-fledged application platform. The proposal to give buttons link-like powers is a symptom of developers wanting to treat the web like a native app without acknowledging the consequences for accessibility, history management, and user expectations.
Look at the comments on the original post. One developer cheers: “Inching our way towards native HTMX.” That’s exactly the problem. HTMX bends the original document model into a reactive application framework. It’s brilliant for some use cases, but it’s also a crutch that lets us ignore the fundamental question: should a button navigate?
Here’s the dirty secret: you can already make a button navigate by wrapping it in a <form> with action. But when you do that, you inherit the form’s baggage—a page reload, a history entry, a form submission event. The article’s author acknowledges this but dismisses it as inconvenient. It’s not inconvenient. It’s a feature. The inconvenience is the guardrail stopping you from breaking the user’s mental model.
I’ve seen this firsthand. A developer on my team added a click handler to a button that called window.location. The button looked like a button, but it acted like a link. Screen readers announced “button, submit”, but then the page abruptly changed. The user was disoriented. The QA team flagged it. The fix? Use a link styled as a button. Simple, semantic, accessible.
Accessibility isn’t a feature. It’s the contract you signed with every user who visits your site.
Proponents of the proposal argue that developers want simplicity. But simplicity at the cost of semantic clarity is a net loss. The web already has a way to navigate: the <a> element. It has a way to submit data: the <form> with a <button>. Trying to merge them only creates a twilight zone where nothing is what it seems.
Take a side: this is dangerous. The proposal is a well-intentioned step toward a “unified” element, but it fractures the web’s most foundational usability principle. Users shouldn’t need to guess whether a click will take them somewhere or do something. They should know.
If you’re building for the web, fight for the distinction. Use <button> for actions, <a> for navigation. Style them to look however you want—but don’t erase their semantic identity. The web is already fragile enough. Don’t break the contract.
We need to protect the semantic web. Not break it. The next time you reach for a button that navigates, ask yourself: is this convenience, or is this laziness? The answer might just save someone’s experience.
FAQ
Q: Isn't this just a minor technical change? Why make a big deal?
A: It's not minor. The semantic distinction between button and link is the foundation of web accessibility. Blind users rely on it to predict behavior. Merging them means every user has to guess. That's a regression, not an improvement.
Q: How does this affect my day-to-day coding?
A: If you're a developer, it means you have to be more disciplined. Instead of reaching for a magic button that can do everything, you need to choose the right element for the job. That means more semantic HTML, more <form> wrappers, and more accurate ARIA roles. It's more work, but it's the right work.
Q: But HTMX is great—why oppose something that makes it easier?
A: HTMX is a powerful tool, but it's an extension of the document model, not a replacement. The proposal to add action/method to buttons is a shortcut that bypasses the existing semantics. It's like putting a car engine in a bicycle frame—it might move, but it won't be safe or predictable. Use HTMX with <a> tags for navigation, not buttons.