W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2004

[whatwg] Save a web page

From: Lachlan Hunt <lachlan.hunt@iinet.net.au>
Date: Sat, 03 Jul 2004 00:38:14 +1000
Message-ID: <40E57356.5080802@iinet.net.au>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:35 UTC