[whatwg] creating a new file via the File API

[David Karger]

Hi,

    What you're doing is certainly connected, but I don't think it 
solves the problem I outlined.  Your approach allows specification of 
the download target as an attribute in html.   That's useful, but what's 
still missing, and I consider important, is a way to connect the html 
document to the "Save As" dialog available on all OSes. <input> tags 
lead browsers to launch the "Open File" dialog, which lets the user 
naturally navigate their file system to select a file to open.   
Browsers also launch the analogous "Save As" dialog, but _only_ when you 
execute a download from a server.  I think it's important to enter the 
same "Save As" dialog programmatically, for client-side generated 
content.  I don't think this raises the security issues discussed at 
mozilla, because the user is engaged in the same interaction as they are 
on any other file download.


On 12/18/2011 11:13 PM, Bronislav Klučka wrote:
> Hi,
>
> This is quite crucial functionality and sadly not being addressed as 
> it would seem, because without it application cannot really be 
> applications (all you can do is to prepare data, upload those data to 
> server and let user download it manually by clicking somewhere, which 
> is annoying, unnecessary,  and quite frankly stupid) .
>
>
> but there is a way howto allow user to save file from javascript 
> without flash
>
> http://www.webnt.cz/demos/034_a_download/
>
> this demo (the generated files) allows you to download/drag'ndrop 
> generated file using JS (no flash)
> it's working in Chrome only at this point
> FF team is having some security issues I've been discussing with them
> https://bugzilla.mozilla.org/show_bug.cgi?id=676619
>
>
>
> B.
>
>
> On 16.12.2011 0:58, David Karger wrote:
>> It isn't clear to me that a "tag" question can be addressed by an 
>> "api" answer.   Even if there is an api for saving to file, isn't 
>> there value to being able to declare your intentions through a tag?  
>> The <input type=file> tag specifies that a user will be able to 
>> interact to specify a file through a dialog.  There's absolutely no 
>> commitment that that file will actually be uploaded or input.  That's 
>> up to the form or the javascript that handles the input.  It seems 
>> entirely consistent to be able to permit specification of a brand new 
>> file in that dialog that <input type="file"> is already creating.   
>> What some javascript _does_ with the specified file might need to be 
>> implemented using a filesaver api, but that's separate from the 
>> declaration of an interaction for specifying the file.
>>
>> On 12/15/2011 6:45 PM, whatwg-request at lists.whatwg.org wrote:
>>
>> On Mon, 15 Aug 2011, David Karger wrote:
>>> /
>> />/  Apologies if I'm revisiting old territory.  I've been doing work 
>> on pure
>> />/  html/javascript applications that work entirely clientside
>> />/  (http://projects.csail.mit.edu/exhibit/Dido).  For persistence, 
>> they
>> />/  read and write local files.  There's already an<input type="file">
>> />/  interface for letting the user specify a file to be read.  And I 
>> can use
>> />/  the same interface, inappropriately, to let the user overwrite a
>> />/  preexisting file.  But things get much messier if I want to let 
>> the user
>> />/  specify a _new_ file to be written, because the file-open dialog 
>> doesn't
>> />/  offer users a way to specify a new filename.  What I'd like to 
>> be able
>> />/  to do is specify a tag, or a invoke some javascript method, that 
>> will
>> />/  produce the "save file" dialog typical of most systems, with a 
>> graphical
>> />/  directory browser but including the option to specify a new 
>> filename.
>> />/  This problem isn't unique to me; a discussion on stackoverflow 
>> appears
>> />/  at
>> />/  
>> http://stackoverflow.com/questions/2897619/using-html5-javascript-to-generate-and-save-a-file
>> />/  where the proposed solution is to use flash---and that would be an
>> />/  unfortunate loss of html5 purity.  They also suggest the hack of 
>> using a
>> />/  data: url but that has size limitations.
>> />/
>> />/  Perhaps<input type="file">  could be given an attribute specifying
>> />/  whether a new filename is permitted?
>> /
>> On Wed, 7 Sep 2011, Eric U wrote:
>>> /
>> />/  This sounds like a job for the FileSaver interface.  Currently no
>> />/  browser implements it, but we at Chrome have been considering 
>> it.  At
>> />/  TPAC last year we discussed it a bit in the WebApps WG meeting; 
>> IIRC we
>> />/  talked about letting it take a URL instead of or in addition to 
>> just a
>> />/  Blob, for more general utility.
>> />/
>> />/  I suggest you bring it up on public-webapps@, where that spec 
>> lives.
>> />/  
>> http://dev.w3.org/2009/dap/file-system/file-writer.html#idl-def-FileSaver
>> /
>> I agree that an API like FileSaver is the right way to do this. Using
>> <input type=file>  wouldn't really fit well because that's more for
>> providing data for upload than providing a file for writing.
>>
>