HTML4 and XHTML insisted that all form elements — including the submit button — were contained within a single <form>…</form> block. While this is rarely an issue, it can lead to design challenges and I certainly recall struggling with early versions of ASP.NET which enforced a single form on every page. In general, if you required an input field outside the form, you’d need JavaScript to import its value when the form was submitted.

One of the lesser-known HTML5 features is the form attribute. It allows you to reference a specific form by its ID on any orphaned field, e.g.

<form id="myform1" method="post">
 <label for="name">name:</label>
 <input type="text" name="name" />

 <label for="email">email:</label>
 <input type="email" name="email" /></form>

<input type="number" form="myform1" name="age" />

<button form="myform1" type="submit">Submit</button>

Interestingly, the form attribute allows you to place a field in one form that is submitted in another. Alternatively, you could change form attributes in JavaScript rather than importing values, e.g.

<script type="text/javascript">// <![CDATA[
// grab fieldx from another form
document.getElementById("myform1").addEventListener("submit", function(e) {

	return true;

}, false);
// ]]></script>

Browser Support

The form attribute is supported in all browsers — except any version of Internet Explorer. For that reason alone, it’s probably not worth using unless your orphaned fields are relatively unimportant and you’re happy to lose data.

But does this feel right? Perhaps it’s because I’ve been writing self-contained forms for many years, but I wouldn’t suggest using the form attribute unless there was no other option. At best, it’s a little inelegant. At worst, it’ll confuse you and your colleagues when you examine the code in a few months time. But it’s reassuring to know it’s there should you need it!

Tags: Forms, HTML5 Dev Center, HTML5 Tutorials & Articles
Craig is a freelance UK web consultant who built his first page for IE2.0 in 1995. Since that time he's been advocating standards, accessibility, and best-practice HTML5 techniques. He's written more than 1,000 articles for SitePoint and you can find him @craigbuckler

Free Guide:

How to Choose the Right Charting Library for Your Application

How do you make sure that the charting library you choose has everything you need? Sign up to receive this detailed guide from FusionCharts, which explores all the factors you need to consider before making the decision.

  • Vaielab

    Can the form attribute have multiple id in it?

    Could be useful for validation (csrf or uniqId). Only one input for multiple form.

    • Craig Buckler

      You can only have one form ID, although it’s quite a nice idea to have many.

  • Wolf_22

    It can’t be anymore confusing than PHP variable-variables… Personally, I think it’s awesome to have this. If it catches on, you’ll potentially see different ways of designing web pages. For example, you might see developers placing all form elements at the bottom but do as they wish with inputs, etc. It could lead to better readability with markup stacks…

    (But this is all tongue-and-cheek.)

    Oh, and replace…
    …you’d need to JavaScript to import…
    …you’d need to use JavaScript to import…


  • 1UnitedPower

    To your question, if it feels right.
    The specification notes: “This feature allows authors to work around the lack of support for nested form elements.”

    But has there ever been a need for nested form-elements? I never stumbled upon this problem.

    And btw. what is the expected behaviour if you assign different values to the form-attribute of a label-element and its corresponding input-element? I could’n find anything about this issue in the spec.

    • Craig Buckler

      The label for attribute refers the the input by its ID, therefore it must be assigned to whichever form that input is assigned to.

  • Ash

    What if you used some JS to insert hidden fields in the element that were mirror fields to the fields that sit outside of the for IE? Since each field outside of the form will have an attribute like form=”myform1″ it would be possible to determine which elements need this mirror function to happen. Then when something is entered into an orphaned field its value would be updated in the hidden fields.

    I think this might already be a non-core detect in Modernizr as “forms-formattribute”.

    • Craig Buckler

      I think there are several ways to create shims for IE and older browsers but I still haven’t thought of a case when I’d want to use it!

  • Christian

    “I certainly recall struggling with early versions of ASP.NET which enforced a single form on every page.”

    I could never for the life of me figure out why it did that. I brought it up one time to a .NET programmer who said, “Because every page is its own form, right?” “Uh . . . no.”

    • Craig Buckler

      I suspect the problem was caused by Microsoft developers considering HTML to be a similar concept to the Windows UI. No one wants to define Windows dialogs by hand and there’s little benefit for doing so. HTML is a different matter but ASP.NET thought it could write code better. The result was tangled tag soup, weird controls which posted back to the server, single forms, IE-only compatibility and multi-megabyte viewstates. You could get around it but it wasn’t always easy.

      Fortunately, ASP.NET MVC has eradicated many of those issues.

Ending Soon
Free SitePoint Premium

Get one free year of unlimited book and course downloads on SitePoint Premium!