W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: File Save As

From: Jonas Sicking <jonas@sicking.cc>
Date: Sat, 5 Jan 2013 15:51:03 -0800
Message-ID: <CA+c2ei9OOgUTNW+tKHnUfEvDbsV4X6JV4sRDGCVi2czTR8+03Q@mail.gmail.com>
To: Florian Bösch <pyalot@gmail.com>
Cc: Webapps WG <public-webapps@w3.org>
I think what we need here is the concept of "open for editing". I.e.
allow a page to open a file not just for reading (like <input
type=file>), but also for writing.

I think there are three questions here:

1. What should the API look like for triggering the "open for editing"
action. E.g. is it some sort of extension of <input type=file>, or is
it an JS-API based solution.
2. What should the API look like once the user has picked a file. Two
options here are FileWriter and FileHandle, proposed by Google and
Mozilla respecively.
3. What should the UI in the browser look like in order to communicate
to the user that this is different from the <input type=file>
file-picker which only allows reading.

The third one is actually the hard one in my mind. Unless we can solve
that I don't think question 1 or 2 are that interesting to discuss.

/ Jonas

On Sat, Jan 5, 2013 at 5:35 AM, Florian Bösch <pyalot@gmail.com> wrote:
> I'm currently working on an Application that requires to save and open
> files from a users computer with a selection dialog.
>
> Opening files works fine by creating an <input type="file"> upon user
> interaction, listening to the change event, triggering a click and
> grabbing the file.
>
> Saving files does not work as smooth:
>
> - The a@download attribute lets me define a downloadable file which I
> can offer from a BlobURL but there are three problems with it: #1 This
> is a two-step UX where first the content has to be produced and then
> the dialog can be shown, it's somewhat counter intuitive. #2 Left
> clicking the link auto-saves to the downloads folder with the selected
> file name (no way to choose a location). #3 Right click Save As is
> even a bit more counter intuitive and the filename for the blob url
> content is not derived from the a@download attribute.
> - There is no way to trigger a native "Save As" dialog
> - There is no way to reproduce the classical "Save" functionality
> where the first save will let you choose a location but subsequent
> saves overwrite that file.
>
>
> Neither the File API nor the FileSaver API (somewhat counter
> intuitively) define any behavior partaining to "Save As" or "Save". As
> far as I can tell there is no standard for this. So far the workaround
> seems to be to include a flash file and trigger the save-as via the
> flash bridge, which I'm sure can't be the ideal situation for the
> webapps WG.
>
> Any suggestions how to alleviate this miserable state of affairs?
>
Received on Saturday, 5 January 2013 23:52:03 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:57 GMT