- From: David Morris <dwm@xpasc.com>
- Date: Mon, 12 Jun 2006 18:40:35 -0700 (PDT)
- To: Julian Reschke <julian.reschke@gmx.de>
- cc: <ietf-http-wg@w3.org>
On Mon, 12 Jun 2006, Julian Reschke wrote: > David Morris schrieb: > > ... > > This is a specific case where the protocol design has ignored the > > realities of application user interaction design. I have found > > no alternatives to form.submit() within onload to achieving rich > > and smooth applications. > > ... > > Now that's an interesting statement. It would be nice if you could > expand on this, because it would be useful to understand what kind of > use cases are solved using this method. Application Example: You have two frames where one depends on the other in some fashion. If the onload for FrameA initiates the load of FrameB, FrameB logic can be sure that FrameA data objects are present. Application Example 2: The application has a main window and a data entry dialog. When the user input from the dialog is commited, the main window requires a reload. The onload for the dialog window initiates the refresh of the main window by calling a javascript method in that windows and then closes the dialog window. Misc. Example: Timing web page loads in the style of www.numion.com's stopwatch facility requires careful coordination of loading two visible frames after the base frameset is loaded. Use of onload to trigger the next step provides that synchronization. Dave Morris
Received on Tuesday, 13 June 2006 01:40:41 UTC