Frankly, I don’t actually know whether this is the right thing to do, or the wrong thing to do, but ever since using jQuery within my applications, I’ve actually stopped using HTML Forms in the proper sense to submit data. It’s not because I’m being lazy, it’s really more about understanding what the point is if I don’t need them.
Update – Let me be quite clear by what I mean in this article. In pure javascript applications which will not work without javascript, I am questioning why to use the <FORM> tag. I completely understand in normal scenarios why you would use it for accessibility reasons, even with a touch of jQuery or JS, but for next gen apps that use buttons to toggle the UI for example, why would you use a standard <FORM> implementation which assumes you are wanting to POST or GET data? My bad for not being clear here…
Traditional Forms
In the traditional sense, forms are used to submit data. You wrap a number of form elements such as input boxes, checkboxes, select boxes etc within <form> tags and set attributes as to how and where to send the form data, ie GET or POST to _self or A.N.Other script.
<form method="POST" action="some.php"> <input type="text" name="first_name" /> <input type="submit" name="submit" value="Submit" /> </form>
Very simple, no problems there. Once “submit” is hit, all data within the <form> is posted to some.php. However, what if you wanted to send some data that isn’t related to the form itself, perhaps a value in a javascript variable, or some value of a CSS parameter… Rather than setting these in hidden fields dynamically when their values change, I’m arguing to scrap the <form> entirely and do it with jQuery.
I’m also thinking – I might actually want to update my application UI with the form data without doing any type of submission of the data elsewhere… again do I need to use a <form>?
jQuery “Forms”
So, this time round, what I am actually doing is forgetting about my <form> tags completely. Ignoring the method to send the data, as well as the location of where to send it. What this does is it stops the browser from taking control of the submission process, and let’s me handle it completely with jQuery.
I set up the form elements as usual:
<div><input type="text" name="first_name" /> <input type="submit" name="submit" value="Submit" /></div>
The difference this time round is we need to wire up a click event to the button to do something
$("#submit").click(function(){
var firstName = $("#first_name").val();
$.post("some.php", {fName: firstName, someVar: aJSVariable}, function(){
$("#someDivContainer").text(firstName + " Sent Successfully!");
});
});
Ultimately, you can achieve all this with or without <FORM> tags, however I guess my argument here is – is there any reason why I should be using them? I am purposely leaving them out because they are not needed. This approach does pass W3C validation for XHTML 1.0 Strict – so is compliant – I just wonder if it’s really the right approach for or against. I’ll open it up to the room…
Tools to help you learn…
 Learning jQuery 1.3 |
 Amazon Kindle 2 |
 jQuery UI 1.6 |
Similar Articles:
11 jQuery Plugins to Enhance HTML Dropdowns
Custom 404 with jQuery and jQuery UI
Using jQuery for great user feedback
Authenticating Twitter API calls with PHP & jQuery
Recovery.gov uses jQuery on Drupal
While it may pass validation it’s not particularly good practice to handle forms in this way.
I always cater for users with javascript turned off so that the forms will validate and process through traditional POST methods and then add any extra functionality using JQuery (returning false so that the form submit never gets processed if the javascript handles it).
I know that these days 99% of browsers can handle javascript and maybe it’s an old technique but I’m still sceptical about relying on it to handle these things without a fallback.
ps. Great blog by the way.
I do use the very same technic for smallish forms Steve. Hovewer, in a large MVC app with many complex forms you really want to be able to use $(form).serialize( ) and $(form).serializeArray( ) methods to cut down developpement time on these forms management.
I don’t have the time to test it however, these methods might also work from another selector than a form dom reference, if it’s the case, please, disregard this comment.
Anyway, thanks for sharing
Thanks Tom for your insight…
Cheers Nicolas – good to hear from you on this one!
$(’#submit’).click() – does that mean when a user presses ‘Enter’ it won’t submit? Because I wouldn’t want to lose that functionality.
I’m not against this technique per se, but it doesn’t seem very semantic to me. HTML5 brings more tags to use instead of just div – header, nav, article, etc… To help make markup more semantic, this approach seems to be going the other way.
You ask if there’s any reason to use them, I would say is there any reason not to.
I’ve had mixed results with the ‘Enter’ key press which were undesirable.. The page refreshing on a post for example in IE in particular. This was one of the main reasons why I stopped using them.
Thx for the response!
You’re welcome. I’ve never had any problems with Enter key presses using jQuery Form plugin.
This makes me feel a bit uneasy! I’d recommend capturing the $(’form’).submit() event and using return false or event.preventDefault() to do what you want to do before the form is posted.
If you still need the form to be posted after that, you can do it programmatically!
Happy with that – just want to know why you feel uneasy
Fair enough.
Mostly it’s for accessibility reasons – I believe every form that is submitted using Ajax should work with javascript off.
It’s partly for semantic reasons too – if it’s a form, call it a form!
There may also be problems for disabled users if you leave off the form tags. Some accessible browser technologies may rely on the context provided by properly attributed form tags in order to alert blind users about how to interact with form elements.
very good points there… thank you all!!
Nice writeup – one technical reason why you’d still need a normal form is for posting file data. An XMLHttpRequest is incapable of posting multipart form data.
Of course it’s still possible to move this into a library of sorts. If you need a dynamic image form post, the way to do it is to specify an invisible iframe as the target, then watch the iframe for onload and onreadystatechange events. I don’t know if jQuery handles this or not – I’d have to check.
Thanks for the writeup Steve.
It’s been drilled in my head by the last couple of jobs that accessibility is a big deal – but I’m still unclear whether that means we have to cater to the no javascript crowd.
Most of the people are using the noscript addon for Firefox — although that allows ’script on/off’ per site.
Another thought – there can be multiple elements and submit buttons per page – wouldn’t the lack of them confuse a screen reader / web client for the disabled?
Still, I agree with your premise – the form element seems a little bit antiquated by this stage.
What if the user has javascript disabled? He won’t be able to submit the form
I already stated – this is purely for javascript only applications – It’s in red at the top of the article…