- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 18 Oct 2013 17:40:57 -0700
- To: Jeremie Patonnier <jeremie.patonnier@gmail.com>
- Cc: Ehsan Akhgari <ehsan.akhgari@gmail.com>, public-webapps <public-webapps@w3.org>, "dev-webapi@lists.mozilla.org" <dev-webapi@lists.mozilla.org>
On Fri, Oct 18, 2013 at 11:11 AM, Jeremie Patonnier <jeremie.patonnier@gmail.com> wrote: > My proposal does not suggest to do something different than what is > currently possible (except the silent saving). Just to ease the life of Web > dev by avoiding them to work around their usual problem: > > - Instantiate a full DOM object and listen for its events just to pick a > file sucks > - Being unable to silently save a file granted by the user to be savable > sucks. I agree that the current API for bringing up a filepicker is pretty bad. It's something that has come up many times but the appetite for creating a new API that has the same feature set as an existing API has been about the same as it usually is: very low. The ability to open a file with read/write access is definitely an interesting one and one that would be an excellent addition to the web platform. However the trickiest piece is not the exact API. It's how to design the user experience such that users understand that they are giving more than readonly access to a file. I understand that the FileWriter or FileSaver APIs from Google could be part of a solution that did this, but as far as I can tell neither is enough on their own, at least as defined in [1]. If the Google API or implementation allowed opening files in read/write mode, can you show an example snippet of code that triggers this? [1] http://dev.w3.org/2009/dap/file-system/file-writer.html / Jonas
Received on Saturday, 19 October 2013 00:41:56 UTC