- From: Lachlan Hunt <lachlan.hunt@iinet.net.au>
- Date: Sat, 03 Jul 2004 00:38:14 +1000
voracity wrote: > Lachlan Hunt wrote: > > > Yes, but I'm more concerned that the author will be given control > > over something that is entirely the responsibility of the user agent. > > What specific 'something' is the responsibility of the user agent? _Why_ > is it the responsibility of the user agent? Well, duh! saving the document... that is the subject of this thread isn't it? It's the responsibility of the user agent because it's the user agent that has access to the file system to write the file. > > Ok, so in the example I gave earlier, after they saved the document, > > they would only see that one paragrah that said "Sorry, you cannot save > > this document" (assuming I didn't make any mistakes in the script) > > Yep. Except if the author wrote that, it'd be technically incorrect, > because the user can always save the _document_. The only thing the > author could prevent is the saving of the document in it's current > state. Well, at the time, I didn't realise you were intending it to be a seperate option. (And not even that, with a knowledgable user willing to break > copyright law. That's not as bad as it sounds --- user agent style > sheets that block ads very likely break copyright law.) What? How is a user hiding or blocking an advertisment from being dispalyed on their system in any breach of copyright laws? It's just not liked by the marketing people who rely on advertising for one of their primary sources of income. > If you object to using a special function for this, I might be able to > appease you. Presumably you don't object to built-in functions. Think of > the 'restore state' function as a built-in function, except that it gets > dynamically generated by the system at each save and is only called > internally. If it's built into the user agent, then that's fine. That's exactly what I've been saying about it being the responsibiltiy of the user agent all along. > I think I can describe this best by (crude) example: > > ... > window.onSave = function() {...} > > function restoreState() {...} > ... > <body onload="restoreState();"> So how would that interract with any other onload events or initialization scripts that usually run as the page loads? Would it overwrite any changes made by those scripts, or would those other scripts override the values set by the restore function? It all depends on the order within the document and the order in which they are executed, which would be the source of many bugs and in some cases, cause unpredictable behaviour. However, despite all my reasons against this proposal, I seriously do not see any use cases where such a feature would be required, especially one that can be controlled by the author. If you simply want to be able to close the browser, and then return to the page later, then that doesn't require the author to provide a script to perform the function, and you can't expect that an author would have written scripts to do that. The only reliable way to ensure that the state is retained as you, the user, would like is to allow the user agent to perform all the tasks required, without any help from an authors script. This could be implemented as a remember state option in the browser, which could then be loaded next time the browser starts. A basic feature like this already exists, Opera gives the choice to start the browser at the last address visited before exiting. The user agent should be able to perform any optimization required, which would work much better than any author written script, especially one that simply writes all the values to strings and places them in a new element within the document. That would then cause problems if the user reopened the file with scripting disabled. -- Lachlan Hunt http://www.lachy.id.au/ lachlan.hunt at lachy.id.au
Received on Friday, 2 July 2004 07:38:14 UTC