- From: Eric Uhrhane <ericu@google.com>
- Date: Fri, 2 Apr 2010 17:53:01 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Robin Berjon <robin@berjon.com>, Darin Fisher <darin@chromium.org>, Michael Nordman <michaeln@google.com>, Web Applications Working Group WG <public-webapps@w3.org>
On Wed, Mar 31, 2010 at 3:55 PM, Jonas Sicking <jonas@sicking.cc> 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.
>
> So we could allow FileWriter to be created directly in addition to
> using <input type=saveas>. When instantiated directly any call to
> .write will bring up a save-as dialog. This is useful for the cases
> where Darin and others wanted to use content-disposition to bring up
> the save-as dialog.
>
> On a separate note, I have no idea how to create UI that makes the
> user understand what they grant when selecting a file destination
> using <input type=saveas>. I.e. that they are granting the web page
> continuous writing (but not reading?) capabilities to the specific
> file location.
They're granting write access to a single location, as with a
download. This explicitly doesn't grant read access, and the write
access doesn't survive the document, so it's not so different from a
slow download. I just sent a proposal for UI to indicate the
difference in another response [1]; sorry, I probably should have
merged several of these emails.
Eric
[1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0009.html
Received on Saturday, 3 April 2010 00:53:50 UTC