[whatwg] creating a new file via the File API
Bronislav.Klucka at bauglir.com
Sun Dec 18 21:35:19 PST 2011
if you look at the generated files examples, what you can see there
(again, only in chrome) is that
1/ I have some data in JS
2/ I create blobbuilder -> blob -> url to that blob
3/ I create a element with URL to that blob and download attribute
4/ I initiate click on that link programmaticaly
the result is is that Save file dialog is opened and when save/ok button
is hit, the blob data is stored in user selected file.
Yes, I'm using download attribute, but URL is JS blob (local data).
I do not see problem here. What are you missing?
And yes, I also do not see security issues here, nothing user cannot do
today with regular download or programmer by uploading data to server
and then download them...
On 19.12.2011 6:26, David Karger wrote:
> 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.
>>> seems entirely consistent to be able to permit specification of a
>>> brand new file in that dialog that <input type="file"> is already
>>> might need to be implemented using a filesaver api, but that's
>>> separate from the declaration of an interaction for specifying the
>>> 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 doesn't
>>> />/ offer users a way to specify a new filename. What I'd like to
>>> be able
>>> that will
>>> />/ 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.
Bronislav.Klucka at bauglir.com <mailto:Bronislav.Klucka at bauglir.com>
* webové aplikace
* software na zakázku
More information about the whatwg