11 Oct
2010
11 Oct
'10
2:12 p.m.
Thanks for your answers, it's clear now.
Caty
On Mon, Oct 11, 2010 at 14:50, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
On 10/11/2010 12:39 PM, Ecaterina Valica wrote:
Hi,
Subject: [Form Buttons: Input vs. Link]
In XWiki we have buttons that are created using input-submit ||
input-button
||<a and the CSS is trying to have the same
style for inputs and links,
even thought is quite difficult (native browser rules differ from case to
case and there are inconsistencies, like
http://jira.xwiki.org/jira/browse/XSCOLIBRI-234 ) and semantically they
have
different functions. We also have some problems
when representing the
buttons, because buttons should be 3D, having the affordance that you can
push them, but that's another story.
So I want to know if there is a special technical reason (JS related? is
more simple to listen to<a?) why we have links and inputs for form submit
actions, or we could use only inputs and make this a standard.
Thanks,
Caty
Normally, all the buttons should be <input type="submit">, but:
- There are some old applications or templates that use <button
onclick>, which is extremely wrong for accessibility, and thus this
should never be used, and all the existing instances should be fixed.
- Some buttons are done with links, since their action is not a submit
action. I'm talking about most Cancel buttons, which shouldn't send the
form content back to the server. Implementing them as submitinput will
send the form content to the server. Sending the form content to the
server means more transfer time (sending bytes through the network),
more memory and processing time (allocating memory for holding the
request data, allocating time for processing the request).
So, I think that we do have to maintain two kinds of buttons:
submitinput, and ahref.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs