- From: Charles Pritchard <chuck@jumis.com>
- Date: Mon, 6 Feb 2012 12:03:53 -0800
On Feb 6, 2012, at 11:49 AM, Boris Zbarsky <bzbarsky at MIT.EDU> wrote: > On 2/6/12 2:26 PM, Bjartur Thorlacius wrote: >> On Mon, 06 Feb 2012 18:59:14 -0000, Boris Zbarsky <bzbarsky at mit.edu> wrote: >>> That really depends on what the application is doing. Depending on >>> input capabilities, you may want to have multiple pages instead of a >>> single page for some sort of configuration setup, for example. >>> >> Whether to use monolithic forms or paginated wizards is a presentation >> thing > > Not on the HTML level. Not if you want to allow useful non-scripted semantic submission of partially-filled-in info in the paginated case. > >> that need not even have anything to do with HTTP. You can fetch >> half the monolithic form and fetch the rest when the user has filled in >> most of former half. > > Not without script. I really didn't like the consequences of server-side scripting to manage dependencies. It was always more work than simply doing the scripting in the client side. It was more prone to error. It let our coders get away with less rugged design. I'm in the responsive and universal design camp. I'm in the accessibility camp. At present, it does require scripting. I'm building web apps, so, scripting comes with that territory. It seems to me like these folk are looking for <iframe defer> and <style defer> and some sort of media selector for the network information API, to minimize bandwidth on metered connections without needing to use scripting to do that work. I'm interested in seeing a solution here. I do not think server-side management is the right one. -Charles
Received on Monday, 6 February 2012 12:03:53 UTC