Feed Sign in with OpenID OpenID

Simon Willison’s Weblog

Multi part forms with Javascript

Andy Arikawa has a nice demonstration showing how multi page forms can be served up as a single page using some simple Javascript, resulting in a clearer form without loading times in between each page.

The concept is great, but the execution has a some subtle flaws—the most important of which is that browsers with Javascript support turned off (but CSS turned on) will not be able to use the form. The culprit is the use of a style="display: none;" attribute on the two divs that should initially be hidden. CSS supporting browsers will follow this rule blindly, even if Javascript is disabled and they will thus be unable to later reveal the hidden page content. The solution is to have all of the elements visible initially, then hide them with a piece of Javascript that executes when the page has loaded.

My other small gripe is the use of javascript: in the href part of the links to activate the toggle function. Dive Into Accessibility has the skinny on why this is a bad idea. Since the toggle links lead to other sections of the form, it makes sense to use the IDs of those sections as the link so that browsers without javascript will still “jump” to the section that is linked to. The Javascript itself can be placed in an onclick attribute (and duplicated in an onkeypress attribute for improved accessibility).

Taking the above points in to account, here’s a reworked version of Andy’s demonstration that should work just fine in browsers with Javascript support disabled.

Posted 12th August 2003 at 10:39 am

This is Multi part forms with Javascript by Simon Willison, posted on 12th August 2003.

View blog reactions

Next: Firebird and Mozilla chrome URLs

Previous: Python script shell integration

36 comments

  1. Great original concept, great rework for accessibility! I'm part of a design project for a series of customer feedback forms that will use Javascript in much this fashion, so I found this post very helpful. Thanks!

    Jay Small - 12th August 2003 13:13 - #

  2. This is a great example where you could use the :target pseudo class.

    Anne van Kesteren - 12th August 2003 13:56 - #

  3. I get a javascript error with IE5/Mac

    Document.contactform.person is not an object

    eric scheid - 12th August 2003 14:11 - #

  4. Simon and all,

    Thanks for pointing out the flaws in my concept. :-)

    I've updated the post to reference Simon's reworking, and unlinked the originals. (E-mail sent to you, Simon, to this effect).

    As for the javascript error mentioned, it was an attempt to focus the first field of the form. Um, can you tell I'm not a JavaScript expert?

    Arikawa - 12th August 2003 15:31 - #

  5. The error happens on Opera 7/Win, too.

    document.contactform is *not* guaranteed to give you the form object. The fact that it did back in Netscape 2, and does still in IE, is an undocumented (AFAICS) shortcut feature.

    Instead, use document.forms.contactform, or document.forms['contactform']. This has the advantage of being clear when you pick a form name that clashes with one of the properties of the form object.

    The same should be done with form elements. So use:

    document.forms.contactform.elements.person.focus() ;

    Andrew Clover - 12th August 2003 16:23 - #

  6. Thanks Andrew. I've always felt a bit uncomfortable with the whole document.formname chain but I didn't realise there was another (proper) way of doing it. I've updated the demo to reflect this.

    Simon Willison - 12th August 2003 17:30 - #

  7. Not sure if this is still a problem, but some time ago when I made a long form using a similar concept of hiding sections, some of the data within the form wasn't being sent on submitting.

    I tracked it down to some browsers wrongly assuming that an input element that resides under an element set to display:none, will not be sent when the form is submitted.

    At the time the way round it was to unhide all sections of the form as the submit button is pressed.

    Dave Page - 13th August 2003 11:09 - #

  8. I think this is a great way to break up long forms. What I would be worried about is users thinking they're on a new page when the click to move to the next step, and using the back button to go back to make changes. At that point, you have the possibility of losing all their information they entered. Would it be a good idea to try to override the back button (if it's even possible) or add the pages to the history via javascript?

    Rob Hudson - 19th August 2003 19:11 - #

  9. Rob has a good point here...I'm trying to implement this for an internal application, and while I love the speed, and how it simplifies the form, I'm nervous about somebody wiping out all their work halfway through. I'm thinking through a number of options. Will post a note (and maybe a sample) when I get something I like.

    Elaine Nelson - 20th August 2003 18:37 - #

  10. One drawback I see: if you validate the submitted data and there's errors, are you expecting them to start on the first page of the form again and click through until they find the incorrect forms?

    Also, would you put the error messages on the individual pages (difficult) or all at the top? this would be far easier but wouldn't relate the errors to the pseudo pages

    Peter Bowyer - 21st August 2003 17:09 - #

  11. Of course I thought it out as soon as I'd posted (yet another thing for my weblog wishlist: editable comments for n minutes after posting, where n ER) - of course you could link the error message to show the correct page of the form.

    Peter Bowyer - 21st August 2003 17:20 - #

  12. mbm

    ,mn,mn - 25th August 2003 19:42 - #

  13. Arikawa, I have a 6 part form that this script would be great for. It will be used internally only so issues with javascript not being enabled and other accessibility issues are not a concern. Since my form is a six part form and the script is only three I added to the array 'partFour', 'partFive', 'partSix'. But when I did that, the script stopped working. I know nwxt to nothing about javascript so I was wondering if you could tell me what i would need to do so I could use the script on arrays larger than the three that are there. thanks mark

    Mark - 28th August 2003 02:29 - #

  14. hii

    vijay - 16th September 2003 06:42 - #

  15. how can i fix the asp panels using asp.net in safari browser... please help me .. thank u

    hemachander - 21st November 2003 10:08 - #

  16. f

    f - 18th April 2004 19:06 - #

  17. f

    f - 18th April 2004 19:06 - #

  18. f

    f - 18th April 2004 19:07 - #

  19. f

    f - 18th April 2004 19:07 - #

  20. gdssgs

    t - 2nd May 2004 15:08 - #

  21. gjdfklgjd wrwerwe

    ewtrwertwe - 28th July 2004 16:49 - #

  22. 34534

    23 - 31st August 2004 17:10 - #

  23. 34534

    23 - 31st August 2004 17:10 - #

  24. 34534

    23 - 31st August 2004 17:19 - #

  25. 34534

    23 - 31st August 2004 17:19 - #

  26. fadfadfasdfdasf

    3dfdf - 29th September 2004 03:49 - #

  27. sdvzsd

    sdvs - 31st March 2005 04:24 - #

  28. I am looking at ways to cache most of a multi-part form through JavaScript. At the moment I am looking at a CGI-generated page with the 'top' form containing only hidden inputs. Using an iframe in this page I reference the first static HTML layout page with tables but no form. Using JavaScript and DOM I populate the static iframe elements (through onload event callback). To move on to the next layout page I intend to change the src of the iframe through DOM (perhaps using onunload event callback to copy the displayed data back into the top form).

    This has several advantages to me, the CGI-generated page is tiny (mostly hidden input fields) while all the iframes and JavaScript are static and can be cached. I can add/delete rows to/from layout tables throught DOM and then add/delete elements to/from the top form on iframe's unload. (I have not been able to add child input elements to a tabledata object so that they are also elements of a containing form. So, by separating the form from the layout, I can have separate input elements in the (hidden) form and in the display table.

    Andy Robb - 14th April 2005 10:32 - #

  29. cvbncb

    vbnbv - 25th May 2005 02:45 - #

  30. sekhar

    chandra - 21st July 2005 08:05 - #

  31. asd

    asd - 22nd September 2005 19:11 - #

  32. d

    d - 21st December 2005 11:16 - #

  33. ggfgfgf

    fgdd - 16th April 2006 17:33 - #

  34. ggfgfgf

    fgdd - 16th April 2006 17:33 - #

  35. bb

    babu pal - 9th June 2006 06:19 - #

  36. sample

    venkata - 17th October 2006 06:09 - #

Comments are closed.

Previously hosted at http://simon.incutio.com/archive/2003/08/12/multiPartForms

A django site