- From: Eric Uhrhane <ericu@google.com>
- Date: Fri, 2 Apr 2010 17:48:37 -0700
- To: Darin Fisher <darin@chromium.org>
- Cc: Jonas Sicking <jonas@sicking.cc>, Robin Berjon <robin@berjon.com>, Michael Nordman <michaeln@google.com>, Web Applications Working Group WG <public-webapps@w3.org>
On Thu, Apr 1, 2010 at 1:03 AM, Darin Fisher <darin@chromium.org> wrote: > On Wed, Mar 31, 2010 at 3:01 PM, Eric Uhrhane <ericu@google.com> wrote: >> >> On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> > On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon <robin@berjon.com> wrote: >> >> On Mar 31, 2010, at 01:56 , Darin Fisher wrote: >> >>> The only way to get a FileWriter at the moment is from <input >> >>> type="saveas">. What is desired is a way to simulate the load of a resource >> >>> with Content-Disposition: attachment that would trigger the browser's >> >>> download manager. >> >> >> >> I don't think that <input type=saveas> is a good solution for this, for >> >> one it falls back to a text input control, which is less than ideal. I think >> >> that the File Writer should trigger downloads on an API call since that >> >> doesn't introduce security issues that aren't already there. I'll make a >> >> proposal for that. >> > >> > Why not simply allow FileWriters be instantiated using: >> > >> > x = new FileWriter; >> > >> > And then make every call to .write open up the save as dialog. >> >> You wouldn't want to prompt on every write; developers might want to >> append a chunk at a time. >> You could prompt on creation, if you didn't mind that being a synchronous >> call. >> >> The reason I made an html element be the way of getting a FileWriter >> was to make the normal usage pattern not involve modal dialogs popping >> up in front of the user unprompted. With an inpput control, they can >> choose when to interact with it, rather than having a speedbump shoved >> in front of them. > > > Please no more JS functions that block on modal dialogs! :-) > @sicking: It seems odd to vary the behavior of .append based on how the > FileWriter was created. Perhaps we should provide some other asynchronous > means of creating a FileWriter? > I also find it a little odd that we are overloading <input> to specify a > save-as > location. Has the idea of an <output type=file> tag been discussed? I don't think output fits as well as input. You're providing to the page the location of the file you want written--that's an input. The page isn't giving output to a form element, it's writing to the filesystem, so an output element doesn't fit very well.
Received on Saturday, 3 April 2010 00:49:26 UTC