[whatwg] Save a web page

Fri Jul 2 10:07:51 PDT 2004

Lachlan Hunt wrote:

>   Well, duh! saving the document... that is the subject of this thread 
> isn't it?

No, saving the _document state_ is the subject of this thread.

> 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.

Absolutely --- writing the file is the responsibility of the UA, for safety. The 
responsibility for _what_ is written is a different question.

This separation of responsibilities is important: it prevents the author from 
damaging the user's system, while still giving the author control over what is 
saved and how.

>   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.

I did say likely (not certain). It depends on what is considered modification. 
Perhaps the original source is the only thing of concern, and not the way in 
which that source is interpreted. I'm dubious, though (translations are covered 
by copyright). Indeed, consider this example: suppose you were authorised to 
make a presentation with the copyrighted file. However, in the presentation, you 
use the user style sheet to block out certain portions. I'm certain that would 
qualify as a breach. However, it's a fuzzy area of law at best, IANAL and I 
certainly don't want to try to make a case that the current crop of copyright 
owners could exploit.

>   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.

Ok.

>> 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.

Yeah. So it would be like standard application development when doing save/load 
files.

If we were to have an onSave event, then all responsibility for saving the page 
state (aside from the DOM tree, if it were already in suitable form) would be up 
to the author. If the author doesn't want state saving, they can block it. If 
the author can't do it properly, then it will be broken. This is what I meant 
before about whose responsibility over what.

>   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.

Here's a simple use case. Imagine the use of WF2 repitition blocks for a table. 
I could quickly write markup for such a table for albums, with headings 
"Artist", "Album Title", "Year". I could add an entry. Then, I could save the 
page state. A little time later, I could reopen the file, add another entry, and 
save the page state. I wouldn't need a network connection or server. And I 
wouldn't need a single other program other than my browser and text editor --- 
or, perhaps not even a text editor, if I grabbed a blank 'albums table file' 
from someone who had written it for me. Then I'd only need a browser --- 
because, in a sense, the file is self-editing.

Now, there's all sorts of interesting issues with respect to the mixing of data 
and code. For example, how do you get a blank albums table (as in 'create new 
albums table'). And how do you migrate your existing data into an improved 
albums table (for example, there is a version you want that has "Genre" as 
another heading). There are at least two solutions for the 'create new albums 
table' problem: keep a blank albums table file always available; or clear out 
the data in an existing albums table file (with decent markup that highlights 
the changing data, this is easy). There is at least one solution for the 
'migrate existing data' option: the UA implements an import/export function for 
the data based on similarities in the old file's and new file's markup semantics.

Of course, sometimes you really do need a server to store the data.

 > 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.

Actually, a basic feature like this has existed since bookmarks (and 
javascript): bookmarks are persistent pieces of data that can store state in the 
URL. All the page has to do is link to itself with the state information to save.

Can't exactly save lots of state information like that, though. (Except maybe in 
moz.)

>   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.

On consideration, I think it would be much better for the UA to handle 
everything and not have an onSave. If the author really wants to optimise the 
document before saving, they can just provide a 'Click to optimise before save' 
link (well, not that wording).

Actually, document.write . . . Silly me. You can already write self-editing 
documents.