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

Re: File Save As

From: Jonas Sicking <jonas@sicking.cc>
Date: Sun, 29 Mar 2015 14:38:20 +0200
Message-ID: <CA+c2ei_QNc_GN7u=ehB5WsckLiTLv_AhWc5xEpgWk6nELrR47A@mail.gmail.com>
To: Florian Bösch <pyalot@gmail.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Webapps WG <public-webapps@w3.org>
On Sun, Mar 29, 2015 at 1:25 PM, Florian Bösch <pyalot@gmail.com> wrote:
> It's been over 2 years since I raised this issue the first time. The
> specification has not been http://www.w3.org/TR/file-writer-api/ updated in
> a year and it states that:
>> Work on this document has been discontinued and it should not be
>> referenced or used as a basis for implementation.
> The problem of how to:
> - Asynchronously write a large file (FileSaver & co.)

The spec at [1] cover this use case. Mozilla is interested in
implementing, and I've heard positive signals from other browser
vendors. Though no commitment yet. [1] covers the same use-cases at
the Google edited API that you are referring to. Which includes
asynchronously writing a large file.

[1] http://w3c.github.io/filesystem-api/Overview.html

> - Right click save-as

This is doable using a blob:-URLs and <a href="..."> or <a href="..." download>

> - Overwrite (simple save)

To my knowledge no serious proposals have been made for solving this
problem. The problem isn't an API one, but a UX one. I.e. it's easy to
design an API which would solve this use case. The hard part is
displaying a UI to the user which makes the user understand that
read/write access is granted to the website, rather than read-only
access as the current filepicker allows.

Once that UI problem is solved, it would be trivial to design an API,
or reuse an existing API, to solve this.

/ Jonas
Received on Sunday, 29 March 2015 12:39:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:44 UTC