W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2005

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

From: Ian Bicking <ianb@colorstudy.com>
Date: Sat, 07 May 2005 00:03:32 -0500
Message-ID: <427C4C24.2090006@colorstudy.com>
Ian Hickson wrote:
>>It's not 100% clear to me how you'd do the equivalent with <button>.
> 
> 
> If backwards compatibility was not an issue:
> 
>    <button name="delete" value="10" action="form" method="post">delete this</button>
> 
> If it was:
> 
>    <form action="form" method="post">
>      <button name="delete" value="10">delete this</button>
>    </form>

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.

> 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.

>>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.

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.

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.

>>>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?
> 
> 
> 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.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org
Received on Friday, 6 May 2005 22:03:32 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:41 UTC