By Craig Buckler

The HTML5 form Attribute

By Craig Buckler

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!

  • Vaielab

    Can the form attribute have multiple id in it?

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

    • 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.

    • 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”.

    • 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.”

    • 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.

Get the latest in Front-end, once a week, for free.