I'm with Jeff here. I'll go a bit further and say that if it has to be a bit more secure (e.g., no caching of any input value pairs) then Posting via buttons is the clear choice for the action in question.
In my recent work, this has come up a lot and I too argued passionately that "actions" should appear as a button no matter the programming details behind it. If it "does something" as opposed to "takes you somewhere", use a button. Document Reads, in this case make sense as links, since that is their historical context. They stem from Ancient Druidic™ hypertext linking, meaning you see more text somewhere else (ala wiki) when you click a link. All of the examples you cite above, Jake, do something, and should be buttons.
In my case, I guess I stand on precedent as the most reliable measure of what is "standard". Static links were in use long before CGI enabled forms with buttons were prolific, and when buttons did appear, most of them were (as someone before me has said) submit buttons.
I'm with Jeff here. I'll go a bit further and say that if it has to be a bit more secure (e.g., no caching of any input value pairs) then Posting via buttons is the clear choice for the action in question.
In my recent work, this has come up a lot and I too argued passionately that "actions" should appear as a button no matter the programming details behind it. If it "does something" as opposed to "takes you somewhere", use a button. Document Reads, in this case make sense as links, since that is their historical context. They stem from Ancient Druidic™ hypertext linking, meaning you see more text somewhere else (ala wiki) when you click a link. All of the examples you cite above, Jake, do something, and should be buttons.
In my case, I guess I stand on precedent as the most reliable measure of what is "standard". Static links were in use long before CGI enabled forms with buttons were prolific, and when buttons did appear, most of them were (as someone before me has said) submit buttons.