html5 form attribute

the form attribute

<form id="form1"></form> <input form="form1"/> As is often the case, the spec explains what the new attribute represents and how it should be implemented, but it fails to give real insights into why it was introduced in the first place. After all, why would you want to put an input element outside the form element it belongs to? As someone who values structural logic, it sounds like a very weird use case to begin with.

I asked the whatwg for an explanation and I must admit they did come up with a pretty good example. As you will already know, html has a couple of fixed tag-structures that cannot be broken or interrupted. There's ul>li, fieldset>legend and table>tbody>tr>td. In most cases this won't present much of a problem as the structure consists of only two elements, allowing you for example to wrap a form inside a li-element if needed.

But structures like table>..>td and dl>dd+dt won't allow you to do such a thing. You cannot provide a form that spans the contents of an entire tr, nor can you provide one that does the same for a dd+dt couple. This is where the form attribute comes in handy, as you can simply put a form in a td (I guess the one that holds the submit button) and link the inputs in other tds to that particular form.

It would've been a lot easier to take the xhtml2 route (remember the proposition to introduce the href attribute on all elements - a similar idea could be raised for forms), sadly backward compatibility restraints prohibit such changes in the html5 spec.

reservations

My main reservation is that this proposition breaks the logical structure of html. In 99% of all cases it is possible to identify one logical (semantical) unit with one single html element (+ combination of classes or whatever extra-semantical method you like using). Very few exceptions exist, and the only one I know of (dd+dt) doesn't exactly enjoy my approval either. But even that example exists only within the confines of its parent dl element.

Now, it's not the first time an html element is allowed to detach itself from the structure it logically belongs to, but it is the first one to actually require this. Other similar pairs (like label-input and img-map) can also be linked through attributes and ids, but a responsible htmler will still make sure that his code remains structurally sound. The form attribute was conceived to counter such sound structures and to allow people to break through these typical structural html limitations. My gut feeling tell me this is not a good thing.

Another big issue is support for screen reader users. Until their software supports these extra form specifications, they will have no clue whatsoever that they missed some form fields in the process of filling in the data. But it's not only screen readers that will suffer, regular users too might be confused what form fields they are actually submitting, as the front-end might be wired completely different that the design suggests. This is of course already possible with css and javascript today, but those technologies do throw up an extra barrier. The form attribute is not a direct attack on accessibility and usability of course, but it does make it easier to break such best practices.

Finally, I'm a little afraid of how easy it will be to abuse this attribute. Similar to the remark above, it's already possible to position a "receive newsletter" checkbox outside the designed form and still have it submitted, but it still requires some dirty work to make it all work. The form attribute actually invites such behavior and makes it just a little too simple for malicious marketeers to fuck around with us.

nested forms

One final advantage of this new attribute is that it will be a lot easier to avoid problems with nested forms, as you can play around with the actual input fields and just link them to their respective form elements using the form attribute. Then again, I would've just preferred native support for nested forms instead of this somewhat hacky and undeniably dirty solution.

conclusion

The form attribute improves on one interesting use case, but it doesn't exactly fix anything that was impossible to accomplish in the past. At the same time, it opens a few doors I'd rather see kept shut. Structural validity and structural logic are two important aspects of writing quality html code, and if a property like this leads to a slippery slope situation than we'll end up with code hell real quick.

I might opt to use it for its intended purpose, namely to generate tr-spanning forms, but aside from that single use case I hope it's not a property that will become widely spread. If people not familiar with the ins and outs of writing html come across a property like this (ie back-end devs writing html code), I predict the end of the world, full apocalypse with lots of fire and blazing horsemen included.

Oh, and one final word of advise: if you want to start using it right away, provide javascript fallback support and make sure you don't use it for critical input data. Better safe than sorry, right?