On 2017-04-17 13:53, duanyao wrote:
For single page application, browsers restrict `foo.html`'s permission
to `foo_files/` in the same parent directory. Note that it is already a common 
practice for browsers
to save a page's resource to a `xxx_files/` directory; browsers just need to 
grant the permission
of `xxx_files/`.

I like that idea. But there is no need to treat single and multipage differently is there?


d:\documents\test.html
d:\documents\test.html_files\page2.html
d:\documents\test.html_files\page3.html

This can handle multipage fine as well.
Anything in the folder test.html_files is considered sandboxed under test.html

This would allow a user (for a soundboard) to drop audio files into
d:\documents\test.html_files\sounds\jingle\
d:\documents\test.html_files\sounds\loops\
and so on.

And if writing ability is added to javasript then write permission could be given to those folders (so audio files could be created and stored without "downloading" them each time)

I just checked what naming Chrome does and it uses the page title. I can't recall what the other browsers do. And adds _files to it.

So granting read/write/listing permissions for the html file to that folder and it's subfolders would certainly make single page offline apps possible.

I have not tested how editing/adding to this folder affect things, deleting the html file also deletes the folder (at least on Windows 10, and I seem to recall on Windows 7 as well). I'm not sure if a offline app needs the folder linked to the html file or not. A web developer might create the folder manually in which case there will be no link. And if zipped and moved to a different system/downloaded by users then any such html and folder linking will be lost as well.

Maybe instead of d:\documents\test.html_files\
d:\documents\test.html_data\ could be used?
This would also distinguish it from the current user saved webpages.



--
Unless specified otherwise, anything I write publicly is considered Public Domain (CC0).
Roger Hågensen,
Freelancer, Norway.

Reply via email to