[whatwg] A thought: <a href="..." method="post">

[Ian Hickson]

On Fri, 6 May 2005, Ian Bicking wrote:
>
> I was just thinking about the recent problems introduced by the Google 
> Web Accelerator following links that have side effects (the typical <a 
> href="form?delete=10">[delete this]</a> stuff).  One of the issues is 
> that doing the Right Thing means creating a form, and that effects the 
> UI, and of course the nesting form issue and all that.  The Web Forms 
> spec deals with this some, with the action attribute for submit buttons 
> and some other details.
> 
> A related extension might be a method attribute to anchor tags.  One 
> might expect <a href="form?delete=10" method="POST">[delete this]</a> to 
> do a post request to "form" with a request body of "delete=10".  Or it 
> could do a post with an empty request body, but unfortunately a large 
> number of web frameworks ignore URL variables in post requests.

An interesting idea.


> The benefit is that this would be easy to apply to current applications, 
> would generally be backward compatible with all user agents (as long as 
> the server respected GET responses), and can be implemented in 
> Javascript fairly easy. And for many applications this is purely a 
> template change, not requiring any server code changes.  The Google Web 
> Accelerator will still be broken (the method attribute wouldn't 
> magically appear on all the many applications out there), but at least 
> conscientious web developers would have a fairly simple option to do the 
> right thing.
> 
> Anyway, just an idea that occurred to me; I tried searching the archives 
> a bit and didn't notice anything on the topic.

My feeling now isn't really different from my feeling when you originally 
posted this:

On Fri, 6 May 2005, Ian Bicking wrote:
> > 
> > This has been brought up several times, although I don't remember the 
> > past reasonings for it not being added to the spec.
> > 
> > The main problem I have with it is that it feels wrong. (Yup, I'm 
> > giving really good arguments today!) The <a> element is supposed to be 
> > a hyperlink -- but if you say it can be a form submission, that breaks 
> > that model. Fundamentally, I feel users should be able to always treat 
> > hyperlinks as safe-to-click -- they are links.
> > 
> > So I would say that any time an author needs something to have UI that 
> > is a submission, it should be clearly submission UI. And that would be 
> > a <button> or <input>, not an <a> hyperlink.
> > 
> > In short, I would say that <a href="delete">delete</a> is 
> > fundamentally wrong.
> 
> I'd basically agree.  Which perhaps makes the argument stronger -- I 
> agree, and yet when I'm actually writing an application I frequently do 
> this anyway ;)  This is such a common practice, and at least 
> method="post" offers a path to get people to move in the right 
> direction.  Some of the motivations for using anchors is removed by Web 
> Forms, but not entirely.

Given that you can now easily make a submit button without a form, it 
would be interesting to see if this reduces the demand for this:

> It's not 100% clear to me how you'd do the equivalent with <button>.  I 
> guess this is what I'd come up with...
> 
>   <form action="form" method="post" id="delete"></form>
>   ...
>   <button form="delete" name="delete" value="10">delete this</button>

Actually it's simpler. You can just do:

   <button action=form method=post name=delete value=10>delete this</button>

No need for a form.


> And that's not too bad.  If you really didn't want it to look like a 
> button, you could go out of your way to use CSS to do that.  If the UA 
> allowed it (if the UA actually allowed that).  But one major reasons for 
> buttons not being used (besides currently requiring Javascript) is that 
> they don't look very nice in long lists, so control over appearance is 
> important.  But using anchors for actions is so engrained in web 
> developers that it might not be enough of a carrot.

It's hard to know... testing it (by having browsers support the above and 
then seeing if authors adapt over the following years) would be a good 
test, I think.


> > But having said that, a lot of people have asked for this kind of 
> > thing. Should we give up on our ideals in this particular case and 
> > just say that the "method" attribute can change the <a> from being a 
> > simple hyperlink to being part of a submission UI?
> 
> I must admit I don't know what you mean by "submission UI".  If you 
> mean, act like a submit button for the containing form, then no, people 
> use anchors specifically to avoid that.  Or do you mean something else?

I mean, act like a link but do a button's work.


On Sat, 7 May 2005, Daniel O'Connor wrote:
>
> Is this perhaps a problem that is solved with rel="nofollow"?
> 
> I can see where it would be beneficial to have a profile of link 
> relationship types to denote functional links.
> 
> ie
> <a href="" rel="edit nofollow admin"></a>
> to say "this is a link which is used for editing and administration,
> don't follow it".
> 
> That neatly describes the link functionality in a set of known terms, 
> and avoid a lot of the mess with prefetching...

Ironically, nofollow doesn't really mean that it shouldn't be followed, 
just that the linking site doesn't endorse it (e.g. because the link was 
added by untrusted users).

But yes, we could maybe address this by adding new rel types... it's just 
unclear to me that Web authors who are writing pages that have 
side-effects in response to GET are going to be savvy enough to use the 
new rel types.


On Sat, 7 May 2005, Ian Bicking wrote:
> 
> I'm specifically thinking of places where you'd need to use Javascript 
> now. For instance:
> 
> <form action="edit" method="POST">
> 1: <input type="text" name="address-1" value="123 N. K St.">
> <a href="delete?id=1">delete</a><br>
> 2: ...
> </form>
> 
> Now, there's also good reasons to submit the entire form for a delete 
> (and saving any changes to other fields), but this isn't the only time 
> this kind of layout makes sense, and because a form's scope is tied to 
> the layout and you can't have nested forms, there's no good way out.  
> My impression from the spec was that the use of <button> would do the 
> same thing, submitting the entire enclosing form.  That's why in my 
> example I had a separate empty form, which more closely duplicates the 
> way people use links.

Yeah, you can have a separate form that does this too.


> > Note that using a link for this is somewhat of a hack:
> > 
> >    <a href="form?delete=10" method="post">delete this</a>
> > 
> > We're making the submission URI a magic string, which is suboptimal at 
> > best. I'd feel more comfortable with something like:
> > 
> >    <a href="form" body="delete=10" method="post">delete this</a>
> > 
> > ...but of course that wouldn't be backwards compatible.
> 
> Hrm... thinking it out, it does become less appealing.  The first is 
> comfortably similar to the current way links are composed.  The second 
> is more accurate but it doesn't feel comfortably similar to traditional 
> anchors.

True.


> > > But one major reasons for buttons not being used (besides currently 
> > > requiring Javascript) is that they don't look very nice in long 
> > > lists, so control over appearance is important.
> > 
> > How does this work in native UIs? People don't use links there. Why is 
> > this different?
> 
> Native UIs are very different from web pages.  Maybe it's just different 
> expectations, since web pages are far more stylable than most all 
> toolkits. Maybe it's that there's no custom widgets and so links are 
> used for things that in native UIs that often work very differently.

Native UIs have links these days. They just don't use them for things like 
"delete by data". I don't see why Web UI should be different.


> For instance, in a native UI you'd usually select the item and hit a 
> delete button.  But this kind of selection isn't typically feasible in a 
> web page.

We're trying to change that though, e.g. with <datagrid>.


> There's also a question of visual weight.  Things in a native UI are 
> hidden behind menus and dialogs.  Navigation in a web application is 
> typically more transparent, with far less interstitial dialogs.  For 
> instance, I wouldn't put a "logout" link as a button, even though it has 
> a side effect; I'd consider the button distracting.  (A fairly 
> danger-free side effect, but a side effect nonetheless.)  Buttons direct 
> user's attention, so they should be suggestive of a likely next step. If 
> there's 20 buttons on a page, that is very difficult for the user to 
> process.  That's not to say it's unresolvable -- you can use icons on 
> less significant buttons to make them more compact and visually less 
> attention-grabbing.

Granted.


> > That's exactly what I meant. People shouldn't avoid it -- something 
> > that looks like a link should be a fricking link. I should see the URI 
> > in the status bar and be able to copy it and paste it and open 
> > multiple windows and so forth and it should all just be idempotent.
> 
> My point was that these links typically represent actions that are 
> independent of their encosing form (if any form exists).  That's what I 
> think people are often trying to accomplish with these links.  And 
> actually, I think that might be a good justification/explanation why 
> people are drawn to links for certain actions; they represent an action 
> that does not take any context in the page.

But it does, otherwise there wouldn't be an entity body to the POST (e.g. 
id=1 in the example above)...


On Sat, 7 May 2005, Henri Sivonen wrote:
> 
> There'd be a design bug somewhere if the UI wasn't affected! When 
> something looks like a link to, the user has a good reason to expect 
> that following the link causes a safe retrieval operation. When 
> something looks like a button, the user has a reason to understand that 
> pressing the button may cause an unsafe operation.

I agree.


On Sat, 7 May 2005, Ian Bicking wrote:
> 
> I think it's sufficient to note that this is an *extremely* common 
> pattern, regardless of RFC 2616.  I think this might be a constructive 
> place to discuss why it is so common, and what could be provided to web 
> developers so they can do the right thing, but I don't think much is 
> achieved by just saying that the majority of web developers are wrong. 
> And it's the majority of web developers that use these kinds of links, 
> regardless of spec.  Heck, Google uses these kinds of links.

Indeed. I wonder if it's just that buttons are too hard to use right now 
(requiring a form, not possible to nest in another form, etc).


> I'm just trying to explain why this "incorrect" practice is so common. I 
> haven't thought about it a lot before now, so I'm making it up as I go 
> along, but emperically there must be reasons.  It then would be helpful 
> to give developers tools that address those reasons, but allow them to 
> use POST the way they should.

I agreee. I think we should see if the WF2 features help with this, and if 
they don't we should revisit this and maybe add method="" to <a>.


On Sun, 8 May 2005, Henri Sivonen wrote:
> 
> I can think of the following reasons:
> 1) A very large number of people doing Web stuff are clueless and incompetent.
> 2) Many people haven't gotten in the habit of making page-wide forms.
> 3) A link is less verbose to type than a submit button.
> 4) Many people find submit buttons bulky and the buttons cannot be universally
> styled to be less bulky.
> 
> I think the last one is a big deal when the graphics deezyner overrides 
> RFC 2616. But things that please them belong in CSS.

Valid points, IMHO.


On Sun, 8 May 2005, James Graham wrote:
> 
> I'm not sure that users (the vast majority of users who haven't even 
> heard the term RFC, let alone read one) have any particular expectation 
> for the safety of clicking on a link.

Maybe not an expectation they could vocalise, but I wouldn't be surprised 
if they thought that links were safer than buttons subconsiously.


> The fact that so many webapps use links for unsafe operations kind-of 
> supports that view. Plus, design _is_ important in these things and 
> submit-style buttons don't always make good UI.

When I look at typical UIs I come across each day, I still find that 
things that actually _do_ something are buttons, and things that are 
"safe" are links.


> Consider the example of a webmail application. These often allow 
> messages to be retrieved by clicking on hyperlinks containing the 
> subject line*. This is apparently all well and good because retrieving a 
> message is sounds like a simple GET-friendly operation. Except that the 
> act of retrieving a message often has the side effect of marking the 
> message read in some way (not an unsafe operation per-se but one that 
> should only be initiated by a user).

Sure, but to the user all that's happened is that they've viewed it. The 
"read" state is just describing that.


> So with the current HTML spec, one has the option of a) using hyperlinks 
> to retrieve messages so sticking with a familiar and well understood UI 
> paradigm but violating HTTP and breaking e.g. precaching in UAs, b) 
> using some sort of form for retrieve messages so making the UI ugly and 
> probably harder to navigate, especially for users familiar with approach 
> a), or c) requiring scripting for basic functionality (retrieving 
> messages and/or marking read messages as read).

I agree that it's hard for the server to know if an e-mail was viewed due 
to prefetching or by the user. But in general I think that this is a GET 
case, not a POST case.


On Mon, 9 May 2005, Sjoerd Visscher wrote:
> 
> What this shows is that marking a message read when it is retrieved is a 
> bad idea. Retrieving a message must be done with GET, so that it can be 
> cached. Setting the read state should be done seperately with POST.
> 
> Most e-mail clients only mark an item read when it's open for a few 
> seconds, it's a bonus that you can do that too.

That's certainly an option.


On Mon, 9 May 2005, James Graham wrote:
> 
> But can you do it such that it will work without javascript? I consider 
> distinguishing read/unread messages to be a basic enough feature that it 
> should be possible to implement it without requiring client-side 
> scripting. In this case, the obvious implementation would be a 
> javascript function called when the message was recieved that performed 
> a background POST request to update the read flag on the message. Is 
> there a better way?

Good question.


> This example isn't unique in assosiating a document request with an 
> implicit change in that status of that document to the user. Another 
> example would be a web-based document management system which had a 
> "recently viewed documents" section. Again, this could be implemented by 
> POSTing a "the document is actually being viewed" notification but 
> that's really complex compared to just putting the logic to update the 
> recently viewed documents list in the request handling function. Better, 
> perhaps, but much more complex and requiring client side code to do 
> something that previously could be handled server side.
> 
> Clearly allowing links with method="post" would help these situations 
> although they would break precaching of the webapp.

I'm not convinced this is a POST link. I'm GETting something, not POSTing 
it.


> Assuming that people dislike <a method="post"> and accept that not all 
> state altering operations imply form controls, it might not be possible 
> for HTML5 to mitigate the additional server-side complexity mandated by 
> requiring that GET operations are shadowed by extra POST operations 
> everytime that requesting part of a web-app has an effect on the state 
> of the app. Even so, we should make it easy to implement the client side 
> part of the deal, preferably in a script-free way.

Well, the ping="" attribute actually does that. :-) But people start 
complaining whenever we have anything does a POST without user consent for 
some reason.


On Wed, 11 May 2005, Mark Wubben wrote:
>
> I think the following things are going on here:
> 1) Because of easier styling links have been used for non-idempotent 
> actions
> 2) The semantics defining such an action are located in the URI, instead 
> of HTTP. Think `/delete/$id`
> 3) A way to solve this would be to use buttons with good styling. The 
> styling will be hard to do cross-browser
> 4) Another way is to use `<a method="post"/>`
> 
> I'd like to expend on point 4. It would be rather easy to create an 
> implementation for older browsers. The problem, however, occurs when the 
> `href` attribute points to the non-idempotent URI: without JS providing 
> the compatibility, it would still evoke a non-idempotent action on the 
> server. A way to solve this is by linking the `href` to a URI which asks 
> for confirmation (through a form), while using an `action` attribute to 
> specify the location of the non-idempotent action. If the spec states 
> that `href` must not equal `action`, we have a solution for the problem.
> 
> An example:
> 
>     <a href="/delete/$id/confirm" action="/delete/$id" method="post">delete</a>
> 
> What do you think?

Well, I'd have the confirmation use a form, but yes.


On Wed, 11 May 2005, Kornel Lesinski wrote:
> 
> That it doesn't look like data to send using POST method. I'm afraid 
> that in most cases it will be used as:
> 
> <a href="#" action="/delete/$id" method="post">delete</a>
> 
> So there must be something that requires authors to use it properly...

On Wed, 11 May 2005, Mark Wubben wrote:
> 
> Hmm, interesting. Perhaps the `href` must link to a resource outside 
> this page? This stuff is getting way too complicated....

On Thu, 12 May 2005, Sjoerd Visscher wrote:
>
> Why? People write browser/standard specific things all the time. If it 
> works for them, who cares?
> 
> I like this proposal because it actually solves the original problem, 
> without a need for Google to change their accelerator code.

I certainly agree that servers should be doing confirmations when 
receiving a GET for something that should be a POST. But that doesn't stop 
the original problem unless we also add <a method="">, which isn't a given 
IMHO, as noted above.


On Fri, 13 May 2005, Michael Gratton wrote:
> 
> No, it won't in many/most cases.
> 
> The Google Accelerator (and every other spidering tool, such as wget) 
> will still fetch those links using GET because they are not aware of the 
> new semantics implied by method="post". Most web applications I have 
> seen (certainly nearly every one written in Java) do not differentiate 
> between parameters provided by a GET or a POST; you can do either and 
> the application will work in the same way. So the Accelerator will keep 
> on fetching those links and applications will still perform some 
> non-idempotent action and we will still have the same problem.

Well, the confirmation could be a form with POST.


> Since implementing this proposal to solve the Google Accelerator problem 
> means both modifying existing UA to support it and/or fixing the web 
> apps that are broken anyway, I would rather just fix the broken web apps 
> in the first place and not implement this proposal.

I agree.


On Fri, 13 May 2005, Henri Sivonen wrote:
> 
> Of the various server-side frameworks available Java servlets are among 
> the most cluefully designed when it comes to getting HTTP right. If a 
> developer calls doPost from doGet, there is nothing the framework 
> designer can do about it.
> 
> I'm still -1 on changing the specs to accommodate people who have been 
> ignoring RFC 2616.

I rather agree.


> By the way, the main problem with the publicized case was that their 
> non-idempotent GETs did not have query strings. Usually the people who 
> don't respect the idempotency of GETs also have crufty URLs with query 
> strings so that a robot can apply heuristics to avoid query strings.

Interesting.


On Fri, 13 May 2005, James Graham wrote:
> 
> That seems to be based on the belief that all things which look like 
> links must correspond to idempotent actions. I don't think this is true 
> and, in general, think that trying to couple the user interface to the 
> underlying protocol is a bad idea.

You disagree that users subconsciously think links are safe?


On Fri, 13 May 2005, Kornel Lesinski wrote:
> 
> Links are not coupled with http GET method. You may link to any resource 
> using any protocol, but following a link should not have side-effects - 
> by design.
> 
> Web applications usually don't have undo, so IMHO it should be clear 
> that click on certain UI elements has side effects.
> 
> Difference between radio buttons and checkboxes is quite clear by looks 
> of them. There should be difference between links and buttons as well, 
> because one _goes_ somewhere, and another _does_ something.

I agree.


On Fri, 13 May 2005, James Graham wrote:
> 
> But that's already unclear. Given a button on a web page it's impossible 
> (without context) to tell if it has side effects or not. If I click the 
> "Search" button on Google, it has no side effects yet the "Submit Order" 
> (or whatever the exact working is) button on Amazon, despite being 
> exactly the same type of UI element, has side effects. The same is true 
> in offline UIs - the Save menu item in my text editor is non-idempotent 
> yet the close-by Open menu item is idempotent. In general, it's hard to 
> think of a class of UI where it's unambiguous which actions will have 
> side effects just from the visual presentation of the elements and 
> without additional contextual information.

I agree that it's not perfect.


> Fortunately for the UI designers, there is an acceptable alternative to 
> a link. It's <span> with javascript to provide the behavior. Even if 
> there was a way to ensure that links were _never_ used for 
> non-idempotent actions, you'd still see link-like elements used for such 
> actions. Unfortunately they'd have none of the semantic value offered by 
> <a> elements.

I'm not sure <span> with JavaScript is really acceptable, but yeah.


On Fri, 13 May 2005, Olav Junker Kjær wrote:
> >
> > That seems to be based on the belief that all things which look like 
> > links must correspond to idempotent actions. I don't think this is 
> > true and, in general, think that trying to couple the user interface 
> > to the underlying protocol is a bad idea.
> 
> No, its a great idea! ;-)
> 
> Most users dont know anything about POST or GET, but I believe its a 
> common expectation that you can always safely click links (and then 
> press back to return), while you should think twice about pressing a 
> form button, since it might indicate that you agree to something or 
> wants to buy something or subscribe to a mailinglist or whatever.
> 
> I think this coupling between protocol and UI is one of the great ideas 
> of the web.
> 
> So a link which performs a unsafe action is not just wrong according to 
> HTTP, its also bad UI.

I agree.


On Thu, 12 May 2005, James Graham wrote:
> 
> Wouldn't it work if a single URL in the the href attribute was used for 
> both request types? i.e. simply <a href="/delete/$id" 
> method="post">delete</a> The serverside application would be expected to 
> deal with GET requests on the URI in a sane way e.g. returning a 
> confirmation page with a POSTable form on it - this would account for 
> legacy clients and allow tools like GWA to work.

If we were to do this, that would certainly be a good way of doing it.


On Fri, 13 May 2005, Mikko Rantalainen wrote:
> 
> Broken server apps will be still broken and there's nothing we can write 
> in the spec that forces every developer to create perfect applications.

Indeed.


On Sat, 7 May 2005, Kornel Lesinski wrote:
> 
> I'm strongly against anchors submitting data.
> 
> Main use of it would be for clueless designers that have no idea about 
> usability and UI consistency.
> 
> This illustrates the problem better than words: 
> http://browsehappy.pl/i/apost.png

404. :-(

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'