> > Scripting on the client side for the purposes of content negotiation *does > not work* > Please, understand this. Because browsers pre-fetch as soon as a node is > created there can be no client-side solution to this issue with the current > HTML/JS specifications and browser behaviour. The image linked in the HTML > is *always* requested, and it is requested before the client can do a > damned thing about it. >
> > On 6 Feb 2012, at 20:03, Charles Pritchard wrote: > > > On Feb 6, 2012, at 11:49 AM, Boris Zbarsky <bzbar...@mit.edu> wrote: > > > >> On 2/6/12 2:26 PM, Bjartur Thorlacius wrote: > >>> On Mon, 06 Feb 2012 18:59:14 -0000, Boris Zbarsky <bzbar...@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 > > > >