Is <Input> Well Formed Without a <Form>

Is input well formed without a form ?

<input> without a <form> appears valid, yes (at least for html 4.01, look near the end of 17.2.1):

The elements used to create controls
generally appear inside a FORM
element, but may also appear outside
of a FORM element declaration when
they are used to build user
interfaces. This is discussed in the
section on intrinsic events. Note that
controls outside a form cannot be
successful controls.

Is it good practice to use the form attribute and put input elements outside form tag in HTML?

It is not common practice. In most cases, it offers no benefits but has a drawback: some old browsers do not support the form attribute, so things just don’t work on them.

An input element outside a form element has always been permitted. Such an element just won’t participate in any form submission, if it has no form attribute. But it can be used with client-side scripting.

The form attribute associates, in supporting browsers, the element with a form just as if the element were inside the form. This can be useful in complicated cases where e.g. one row of a table should contain fields of a form, another row fields of another form, etc. You cannot wrap just one row inside a form, and here the attribute comes to rescue: you put a form element inside one cell of the row and refer to that element in fields in other cells with the form attribute.

Is there any danger to using input fields outside/without forms in HTML/Javascript pages?

You should be fine AFAIK. It's ok in the HTML 4.01 standards anyway

http://www.w3.org/TR/html401/interact/forms.html#form-controls

The elements used to create controls generally appear inside a FORM
element, but may also appear outside of a FORM element declaration
when they are used to build user interfaces. This is discussed in the
section on intrinsic events. Note that controls outside a form cannot
be successful controls.

Do I need to wrap my input field in a form if it's just a search function?

From a pure screen reader perspective, having a <form> is a way to group a set of controls together and works best if you specify a label for the form, such as <form aria-label="contact info">.

If you have a simple search field, and presumably an associated search button, then a <form> isn't necessarily needed. However, you should nest your elements in a search landmark by using role="search".

<div role="search">
  <input aria-label="search term">
  <button aria-label="search">
    <i class="magnifier"></i>
  </button>
</div>

It looks like the literal, "search", appears a lot in that code fragment, but the only time "search" has to appear literally is the role attribute.

The aria-label for the input can be whatever string you want. It's what will be read by the screen reader when focus moves to the field. If you have a <label> for your <input>, then the aria-label is not needed.

The <button> just has a magnifier icon and no text so it will require an aria-label too, for the screen reader. If your icon were an <img> instead of an <i>, you could specify the button's label in the img's alt attribute, in which case the <button> wouldn't need an aria-label.

<div role="search">
  <label for="findit">search term</label>
  <input id="findit">
  <button>
    <img src="magnifier.jpg" alt="search">
  </button>
</div>

So the simple answer is, "no", you don't have to put your search in a <form>. But it is strongly encouraged to wrap it in a "search" landmark by using role="search".

Does a hidden input field have to be in a form?

You can place the hidden input outside of the form if you are retrieving the value for an ajax post with jquery. However, if your application must degrade (meaning work without javascript) you should have the hidden input in the form so it gets posted to the server on form submit.

What is the benefit for using form tag?

If I'm removing the tags: "form" and "/form" I'm getting the same
results

Yes. At client site.

Try to post it to a server. You won't be able to read anything at the server side.

In other words , if you add :

<input type="submit" />

The server won't know how to read those values.

Form posts its inputs values (+ select , textarea etc...) to a server. Then you can read those values at the server side.

Other benefits/features

• Giving a name to a form allows you to access its child inputs via their name : alert(myForm.myUserInputName)
• You can cause the post to yield its result/response in other iframe/location using target property.
• You can cause the page to post itself via GET and not via POST , which will cause all input values to be as QueryString.

Input elements independent of forms

I think so, only declare the input inside of form, always for declare input type text should be inside of form html, you can read more about this...

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input

Accesing $pristine property of input without form in Angular?

When you create your <form> element, it will create a $scope variable with the name of your form. For example:

<form name="regForm">
  <div class="row">
    <div class="col-xs-3 align-right">
      <p>Email</p>
    </div>
    <div class="col-xs-7">
      <input type="text" class="form-control" name="email" ng-model="registrationForm.email.value"/>
      <span class="error-label" ng-hide="registrationForm.email.valid"><span class="glyphicon glyphicon-remove"></span>Must be a valid email!</span>
    </div>
  </div>
 </form>

You can access the $pristine using $scope.regForm.email.$pristine.

Without a <form>, simply use ng-form, which will give you the functionality of the form, without needing an actual <form> element. See this post for more information.

Does a HTML page need to be wellformed?

Your friend (who you should stop calling a coder, he isn't) is wrong.

On a practical, down-to-Earth, level, in this specific case, the browsers end the form when they see the </div> end tag. So if you have

<div>
    <form>
</div>
   <input name="what">
    </form>

the input will not be submitted with the form.

And this is one case where the latest browsers all agree on how to act, but in general, different browsers respond differently to errors. (I have compiled some examples of that on my own website, here.)

So your friend may be satisfied with the site working in one particular browser, but he'll be out of luck when the browser updates to a new version. Not to mention other browsers.

As a high level coder, would you deliver an application that compiles, but with warnings?

PS: you said "I just figured out that non well formed HTML won't even show up." but that is a misunderstanding. Most browsers throw an error when they encounter non-well-formed XHTML, but in the case of HTML, they show as much as they can and work very hard on recovering from errors. Still, different browsers use different error-recovery algorithms, so you really really shouldn't count on that.

---

Related Topics