[whatwg] creating a new file via the File API
karger at mit.edu
Sun Dec 18 21:26:30 PST 2011
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:
> 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) .
> without flash
> 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
> 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
>> entirely consistent to be able to permit specification of a brand new
>> file in that dialog that <input type="file"> is already creating.
>> 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
>> />/ (http://projects.csail.mit.edu/exhibit/Dido). For persistence,
>> />/ 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
>> />/ offer users a way to specify a new filename. What I'd like to
>> be able
>> />/ produce the "save file" dialog typical of most systems, with a
>> />/ directory browser but including the option to specify a new
>> />/ This problem isn't unique to me; a discussion on stackoverflow
>> />/ at
>> />/ 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
>> 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.
More information about the whatwg