What is the purpose of the html form tag

Question

I do not understand the purpose of the form tag in html.

I can easily just use any input types perfectly without using the form tag. It almost seems redundant to wrap it around inputs.

Additionally, if I am using ajax to call a server-side page, I can simply use jQuery for that. The only exception is that I noticed that you have to wrap an upload script around a form tag for some reason.

So why are forms still so widely used for simple things like text inputs? It seems like a very archaic and unnecessary thing to do.

I just don't see the benefit or need for it. Maybe I'm missing something.

Solution 1

What you are missing is an understanding of semantic markup, and the DOM.

Realistically, you can pretty much do whatever you want with HTML5 markup, and most browsers will parse it. Last time I checked, WebKit / Blink even allows pseudo-elements inside <input> elements, which is a clear violation of the spec - Gecko not so much. However, doing whatever you like with your markup will undoubtably invalidate it as far as semantics are concerned.

Why do we put <input> elements inside of <form> elements? For the same reason we put <li> tags inside of <ul> and <ol> elements - it's where they belong. It's semantically correct, and helps to define the markup. Parsers, screen readers, and various software can better understand your markup when it is semantically correct - when the markup has meaning, not just structure.

The <form> element also allows you to define method and action attributes, which tell the browser what to do when the form is submitted. AJAX isn't a 100% coverage tool, and as a web developer you should be practicing graceful degradation - forms should be able to be submitted, and data transferred, even when JS is turned off.

Finally, forms are all registered properly in the DOM. We can take a peek at this with JavaScript. If you open up your console on this very page, and type:

document.forms

You'll get a nice collection of all the forms on the page. The searchbar, the comment boxes, the answer box - all proper forms. This interface can be useful for accessing information, and interacting with these elements. For example, forms can be serialized very easily.

Here's some reading material:

• Semantic HTML
• HTML forms guide

Note: <input> elements can be used outside of forms, but if your intention is to submit data in any way, you should be using a form.

---

This is the part of the answer where I flip the question around.

How am I making my life harder by avoiding forms?

First and foremost - container elements. Who needs 'em, right?!

Certainly your little <input> and <button> elements are nested inside some kind of container element? They can't just be floating around in the middle of everything else. So if not a <form>, then what? A <div>? A <span>?

These elements have to reside somewhere, and unless your markup is a crazy mess the container element can just be a form.

No? Oh.

At this point the voices in my head are very curious as to how you create your event handlers for all these different AJAX situations. There must be a lot, if you need to cut down on your markup to save bytes. Then you must create custom functions for each AJAX event that corresponds to each 'set' of elements - which you must have to target individually or with classes, right? Theres no way to really group these elements generically, since we've established that they just kind of roam around the markup, doing whatever until they are needed.

So you custom code a few handlers.

$('#searchButton').on('click', function (e) {
  e.preventDefault();

  var search = $('#mySearch');

  $.ajax({
    url: 'http://example.com/text',
    type: 'GET',
    dataType: 'text',
    data: 'query=' + search.val(),
    success: function (data) {
      console.log(data);
    }
  });
});


$('#login').on('click', function (e) {
  e.preventDefault();
  var user = $('#username'),
      pass = $('#password'),
      rem = $('#remember');
  
  $.ajax({
    url: 'http://example.com/login',
    type: 'POST',
    data: user.add(pass, rem).serialize(),
    dataType: 'text',
    success: function (data) {
      console.log(data);
    }
  });
});

<!-- No containers, extra markup is silly. -->

<input type="text" id="mySearch" value="query" />
<button id="searchButton">Search</button>
<input type="text" id="username" name="username" value="user" />
<input type="password" id="password" name="password" value="pass" />
<input type="checkbox" id="remember" name="remember" checked /> stay logged in
<button id="login">Login</button>

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>

This is the part where you say something like:

'I totally use reusable functions though. Stop exaggerating.'

Fair enough, but you still need to create these sets of unique elements, or target class sets, right? You still have to group these elements somehow.

Lend me your eyes (or ears, if you're using a screen reader and need some assistance - good thing we could add some ARIA to all this semantic markup, right?), and behold the power of the generic form.

function genericAjaxForm (e) {
  e.preventDefault();
  var form = $(this);
  
  return $.ajax({
    url: form.attr('action'),
    type: form.attr('method'),
    dataType: form.data('type'),
    data: form.serialize()
  });
}

$('#login-form').on('submit', function (e) {
  genericAjaxForm.call(this, e).done(function (data) {
    console.log(data);
  });
});

<form action="http://example.com/login" method="POST" data-type="text" id="login-form">
  <input type="text" name="username" value="user" />
  <input type="password" name="password" value="mypass" />
  <label>
    <input type="checkbox" name="remember" /> Remember me
  </label>

  <button type="submit">Login</button>
</form>

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>

We can use this with any common form, maintain our graceful degradation, and let the form completely describe how it should function. We can expand on this base functionality while keeping a generic style - more modular, less headaches. The JavaScript just worries about its own things, like hiding the appropriate elements, or handling any responses we get.

And now you say:

'But I wrap my pseudo-forms in <div> elements that have specific IDs - I can then target the inputs loosely with with .find, and .serialize them, and ...'

Oh, what's that? You actually wrap your <input> elements in a container?

So why isn't it a form yet?

Solution 2

Form tags are still necessary if you want to be able to submit the form without AJAX (which may be useful in the early stages of development). But even though it's possible to use javascript to submit data without a form tag, a few benefits still come to mind:

1. Using form tags can help people read and understand you code in some cases, by showing them your intentions.
2. The 'submit' method is available on forms. If you have a form with an input[type=submit], and it's not disabled, then when someone hits 'enter' while filling out one of the other form inputs, the form will submit. You can still do that by listening for the 'keydown' event on the input elements, but it's a nice bit of ui that you get for free with form tags.
3. There are be a few other things that only work with a form tag, or are easier with a form tag. Developers will eventually run into these cases, and decide it's easier just to always use them everywhere and avoid problems. Really, the real question is, why not use a form tag?

Solution 3

I had a scenario where single web page had 3 forms, all of which had separate email fields (with different IDs). I wrapped them in separate <div> at first. iOS auto fill on Safari behaved strangely until I wrapped all of them in <form> tags. One of the forms had only one input field, for newsletter subscription. When user auto filled that input, web page was scrolled to next input field which was located on different part of the page.

So, thanks Oka for long post. Tags with semantic meaning should be used whenever possible, because you never know which browser/device doesn't handle other solutions well.

Comments

[Darian]

How do you define the action and method for your form without html <form> tag?

[Oluwafemi]

Ajax is just an alternative way to post a form. Form can be use to send requests specifying the method, action and some people want the postback to occur to refresh their input controls state.

[D-Marc]

If I were to do it in jQuery, I would do use the click() function on the button and inside of that I would use the ajax() function. Much simpler and easier to read code in my opinion. And I can easily refresh the page with simple javascript

[dwjohnston]

I'm suprised that this question receieved downvotes. I totally just googled this.

[Stefano Borini]

@dwjohnston you must be new here...

[3snoW]

Great question! Other reasons I don't like using forms include the fact that it limits your page structure (because you can't have forms inside forms), some serialization quirks like the fact that checkboxes will be ignored if not checked (meaning often I end up manually preparing the submit data), and because HTML is fundamentally the content and structure of the page, while JS is the dynamism. Form elements are overlapping a bit on JS's job, and i like to have my pages structured.

[D-Marc]

Yes, but you don't need to wrap around text inputs like email addresses or passwords in forms in order to submit data. I can easily do that with ajax. Forms do not provide any extra security. However, I can do that with php if I encrypt the data.

[EJTH]

Also, stuff like jQuery's .serialize() only works on form elements.

[D-Marc]

That's a good point with taking a peek at all forms. I can see why that would be seen as an advantage. Besides that, why do you say that inputs should be used inside a form? It doesn't seem to provide any real advantage. Only extra code. I have never read anything online that says that it is semantically incorrect to place inputs outside of forms, so I don't think that it is fair to compare it to uls and ols. And realistically, I would never want anyone to use my websites if they have javascript turned off. Plus that would probably only account for maybe 1% of users online.

[Oka]

Sounds less like you are looking for an answer as to why we use <form> elements, and more like you are trying to to affirm your own markup choices. This is fine, like I said, you are free to do whatever you like with your markup, but I have explained the main reasons why we developers use forms.

[D-Marc]

Great points made. I truly appreciate the fact that you took the time to elaborate your answer more and provide real code examples. I will give forms another try and see if I like doing it like that more. Thanks again for the help. However, don't you think that it is pointless to wrap a form around just one text box?

[Oka]

Depends on the context. An input that doesn't ever directly submit, like a search box that polls an API endpoint exclusively via AJAX on events other than submit, can omit being wrapped in a form since it wouldn't have any functionality without JavaScript. It's not invalid markup to have an <input> outside of a <form>, just possibly poor semantics. If there's a way that the data could be submitted without AJAX, with a proper submit event, a form is probably best. Again, the element needs a container, and <form> elements are block level by default, so they act just like a <div>.

[D-Marc]

This is truly the best answer, in my opinion. Many years later, my conclusion is that proper handling on mobile is probably the best reason to use a form tag.