> Should “Cancel” be a link? No! Its job is to close the edit view. Not only does making this a link incorrectly communicate its purpose—visually and otherwise—but it saddles the form “control” with lots of features, like bookmarking and middle-clicking, that have incorrect behavior.
I don’t get this. Cancel takes you back to the read-only view of the form. So if /resource/edit is the form, cancel just takes you to /resource.
So is this “performing an action” or “navigating somewhere”? Hard to tell. I’m saying that if cancelling a form edit just means ditching the local state to go back to the normal view, that should be a navigation.
Someone straighten this out for me.
I do think cancel is a poor example because it's conceptually very near "go back" - but it doesn't actually mean that. It means "I've changed my mind".
Implementing cancel with a URL is an implementation detail. That's one way to do it, but it's far from the only way. Cancel could also be implemented by hiding a UI element, for example.
If cancellation involves abandoning server-side state, then calling an explicit action on the server could make sense. Buttons submit forms (aka mutate state on the server), links navigate to resources.
HN gets itself twisted into a knot over web dev "best practices" and tries way too hard to put things into certain ontological boxes. I would not overthink this. Empathize with the user and follow the vibes if you want a good UI/UX. Explore the nuance of the design space. Maybe buttons sometimes work for pure navigation too.