Philosophical question:
Say I\'ve got a web app that requires javascript and a modern browser, so progressive enhancement is not an issue. If my form is be
I don't see why you would need to use the form tag here. The only reason to use a form tag (other than to get your markup to validate) is if you are going to have the user "submit" the data using a sumbit input or button tag. If you don't need to do that, then there is no need for the form. However, not sure if it will be considered "valid" markup. If you do use it you can just do <form action="">
as action is the only required attribute of the form tag. However, you do bring up a good point, the future of web applications probably will no longer need the form and traditional submit methodology. Very interesting, and makes me happy. hehe :)
Not that I can see. I'm currently building a web application that uses <form>
s, but I'm using them so I have a fallback method if the user has JavaScript disabled (an e.preventDefault
stops the form posting normally). For your situation, where you're saying the user MUST have JavaScript, a <form>
tag isn't necessary, but it might be an idea to keep it anyway in case browser need to do anything with it, or to access it as a sort of class.
In short, no, you don't need to use <form>
if you're doing pure AJAX, although leaving it in might an idea if you suddenly decide to create fallback code in the future.
AJAX is great but as JamWaffles (+1 to him) said, using form
tags provides a fallback method.
Personally I use form tags, even for things I submit with AJAX because it is syntactically clear and makes it easy to grab all inputs within a specific form. Yes you could do this with a div
or whatever too but as I said, using a form is syntactically nice.
Incidentally, screen readers treat the content inside a form
differently so there are accessibility issues to be considered whichever way you choose to go. Note that anecdotal evidence suggests that Google considers accessibility in its rankings so if SEO is a concern for you, use a form and do it right.
There is at least one important user-experience feature provided specifically by wrapping inputs inside a form tag:
The enter key will submit the form. In fact, in Mobile Safari, this is how you get the "Go" button to appear on the keyboard.
Without a form wrapping the inputs, there is nothing to submit.
You can of course provide enter-key behavior through a keypress event, but I don't know about if this works for mobile devices. I don't know about you, but I'd rather work with the semantics provided by the browser than have to imitate them with events.
In your case, you would simply provide an onsubmit
event handler for the form, which would do your AJAX submit, then return false
, canceling the actual submit.
You can simply provide action=""
(which means "self"), and method
is not required — it defaults to GET
.
Summary: forms OK for MVC, simple web apps, bad for component oriented, rich web apps.
Reason: forms cannot nest other forms: big limitation for a component-oriented architecture.
Details: For typical MVC applications, forms are great. In rich, complex web applications using a lot of javascript and AJAX and with a lot of components here and there, I don't like forms. Reason: forms cannot nest another forms. Then if each component renders a form, components cannot nest each other. Too bad. By changing all forms to divs, I can nest them, and whenever I want to grab all parameters in order to pass them to ajax, I just do (with jQuery):
$("#id_of_my_div").find("[name]").serialize();
(or some other filtering)
instead of:
$("#id_of_my_form").serialize();
Though, for sentimental and semantic reasons, I keep naming my divs something_form when they are acting as forms.
In my opinion: If you use it for semantic reasons, then use it as intended. The action attribute is required (also can be left empty) to be well-formed, also you can separate your URI-s from your js logic, by setting the action attribute, and reading it before the ajax call.