There are dozens of attributes, input types, and APIs in the HTML5 spec, and it seems like more show up on our radar and in our readers every day. If you’ve been alive anytime in the last three years, you’re probably already familiar with some of them, like search and email inputs or the File API. I’ve noticed that one, though, keeps getting overlooked: the humble ‘form’ attribute. No surprise there; it’s not flashy, doesn’t make any visible changes, and doesn’t add any seriously new functionality to the game. But it’s not without a few use cases of its own.
This is one I stumbled across accidentally in mid-March of 2011, when it was first being pushed out in FF4 (Chrome and IE had not yet caught up). For some arcane reason having to do with a legacy datepicker plugin (well before jQuery UI solved all our problems), certain inputs in one of our applications had an extra
form="theform" attribute—unsemantic and certainly not a valid attribute at the time, but apparently it did what it was supposed to do (whatever that was). All of a sudden, our Firefox users were seeing that input’s values disappear in transit. One minute a valid date was entered, the next we got an application exception email about referenced values missing from the URL scope. And only in Firefox, the browser I’d been pushing our clients (mostly IE7-8 users) heavily towards.
After a fair number of hours and a lot of exploratory surgery on our elements, we finally found the culprit. The ‘form’ attribute, previously a non-player, was suddenly doing something: blocking that input from submitting with the rest of the form. Pretty soon we realized why: the form tag had no ID, much less an ID of ‘theform.’ Firefox was scraping the DOM for an entity to handle the input data which didn’t exist. So we deleted the attribute and business carried on as usual. But it left me thinking.
Why It’s Useful
Think about it: a perfectly valid, script-free way to put form elements—any form element in fact—outside their parent <form> tag, while still including their values on form submission.
"But why would I have orphaned form elements?" I hear you ask. How about this: the design for a product page calls for user input in multiple locations around the page, each in their own block level sections. Sure, you could keep them all in the same form and just use CSS to position them around the page, but what if the elements vary by product or by user? Say you’re loading dynamic content which may include elements to a form on your page. Or multiple forms, if it’s a complex page. You could wrap the whole content pane in the form element. Or you could just include the form’s ID in the elements’ ‘form’ attribute and save yourself the hassle.
Here’s a demo for your testing pleasure.
Still not convinced? Here’s where it gets interesting. The ‘form’ attribute can, in theory, accept a list of space-separated IDs belonging to one or more forms the input’s value gets submitted with. In other words, one form element belonging to multiple forms at once.
- Flexibility. Did I mention it’s not just for
<input>tags? Sure, it works with the full range of HTML5′s many input types, but you can also stick it on textareas, selects, buttons, and even fieldsets!
- Full feature support. So maybe I overstated things just a teensy bit when I said this is well supported. Truth is, it works in nearly everything but IE, but with a catch: so far, none of the browsers I’ve tested actually allow the multiple form IDs as has been suggested. In fact, the current draft of the spec doesn’t actually allow for multiple values. Whether this is likely to stay that way is anybody’s guess, but there’s always hope.