It can often be difficult to match functionality with the expectations raised by a design for a website. Often, the coding of a site has to be moulded to fit the design to get the most out of both. This is very true when relating to
forms on websites. Simply put, forms are containers for elements allowing you to create things such as sign-up forms and pages used to capture checkout information.
One issue of effective coding is code re-use. If you have 5 separate forms on a page for example, and all of them share one piece of information, then why would you want to repeat that information more than once?
This can be seen in a very common example – a product page on a website. You will probably find that each variation of the product has its own ‘add to basket’ button so that you can add it to your basket. Each ‘add to basket’ button for each variation is likely to be in its own form element. Depending on the complexities of the site, each variation may submit its product
id along with its variation id to the script that will add the item to your basket. That means that you’ll end up with the following:
Ideally, the product
A new HTML5 element brings us one step closer to this ability, however, its still not quite there.
Let’s look at another, more simplistic example:
Here, we have an element outside the form – email. It’s not a child of the
form element, it’s a sibling, and also that the email input has a
form attribute that matches the
id of the form.
This way, you could also have elements in a second form that actually relate to the first if you wanted. It’s important to note that this will override default browser behaviour, so if you had an element in the second form that referenced the first form, submitting the second form would actually ignore that element.
This feature is fairly new, and as such isn’t supported by anything but the latest betas, but it will certainly be interesting to see how this progresses.