Re: [whatwg] Proposal to drag virtual file out of browser
For future reference, I posted another suggestion to the public-webapps list. Instead of specifying a download URL, you could specify a URL on a type as the source of the data: dataTransfer.setRemoteData(mimeType, url); That could allow for both file downloads and/or lazy loading of data transfers for any type. It still doesn't provide a way for lazy loading of application created content. Perhaps something like: dataTransfer.setLazyData(mimeType, callback); would be appropriate for this. On Fri, Aug 28, 2009 at 4:25 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 17 Aug 2009, Jian Li wrote: The HTML 5 spec defines the event-based drag-and-drop mechanism that could cross the browser boundary. If a draggable element contains a URL, dragging it out of the browser will only copy the URL value. However, in some scenarios, we really want to download the data file from the specified URL, instead of copying the value. Here we propose a way to allow dragging a virtual file denoted by an URL out of the browser boundary. I haven't added this to HTML5, since we've only just gotten as far as getting drag and drop of files _in_ to HTML. However, I've noted this for a future version. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal to drag virtual file out of browser
On Mon, 17 Aug 2009, Jian Li wrote: The HTML 5 spec defines the event-based drag-and-drop mechanism that could cross the browser boundary. If a draggable element contains a URL, dragging it out of the browser will only copy the URL value. However, in some scenarios, we really want to download the data file from the specified URL, instead of copying the value. Here we propose a way to allow dragging a virtual file denoted by an URL out of the browser boundary. I haven't added this to HTML5, since we've only just gotten as far as getting drag and drop of files _in_ to HTML. However, I've noted this for a future version. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal to drag virtual file out of browser
Sounds interesting!
You only mention a singular file, what do you think about multiple files?
Also, would it be possible to hook browser-produced data into this model, so
client-generated data (f ex text, html, pdf) could be dragged out as a
virtual file to the desktop?
Best regards
Mike Wilson
_
From: whatwg-boun...@lists.whatwg.org
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jian Li
Sent: den 18 augusti 2009 03:03
To: whatwg@lists.whatwg.org
Subject: [whatwg] Proposal to drag virtual file out of browser
SUMMARY
The HTML 5 spec defines the event-based drag-and-drop mechanism that could
cross the browser boundary. If a draggable element contains a URL, dragging
it out of the browser will only copy the URL value. However, in some
scenarios, we really want to download the data file from the specified URL,
instead of copying the value. Here we propose a way to allow dragging a
virtual file denoted by an URL out of the browser boundary.
USE CASES
In order to download the attachment from an Internet mail application, the
user will have to click the attachment link and a save dialog will pop up
to let the user select the destination folder. This will normally involves
multiple clicks. Native application, like Outlook, can let the user drag
attachments directly into the destination place, i.e. desktop, which is
really convenient.
WORKAROUNDS
Currently there is no direct support in HTML 5 to support such dragging of
the virtual file. To work around this, a plugin with such capability has to
be installed and used.
PROPOSAL
We propose adding a specific format string to the DataTransfer object:
DownloadURL. The data associated with the DownloadURL format should be
parsed similar to the URL format. When the drag ends in another
application, the remote file described in the associated data URL should be
downloaded and provided to the target application.
For example, here's how one can create a draggable image that results in a
file when dragged:
var dragTarget = document.createElement(img);
dragTarget.src = http://example.com/example-attachment.gif;;
document.body.insertBefore(dragTarget, document.body.firstChild);
dragTarget.addEventListener(dragstart, function(event) {
event.dataTransfer.setData(DownloadURL,
http://example.com/example-download-attachment;);
}, false);
Traditionally allowing the non-image file to be dragged out of the browser
is considered bad. The main danger here is that the user might unknowingly
drag a file that will auto-execute. To address this issue, the browser needs
to mark the dragged file to indicate that it is coming from the Internet.
With this zone marker, the user will be prompted with a security warning
dialog when the dropped file is launched. If a specific platform does not
support zone identifier marker, this feature should be turned off by
default.
We should consider allowing only http and https typed URL in the associated
data for the DownloadURL format. Should we further restrict the download
URL to the same origin?
If the filename is provided in the Content-Disposition header, it should
always be used. Otherwise, it is up to the browser to decide how the
filename is generated from the URL. But once it is chosen, it cannot be
changed.
The drag-and-drop feedback might be decorated with the filename and the
domain from which the file is downloaded. However, the real filename might
be only available when we initiate the download and get back the response
header. To address this, we can download the response header after the drag
is initiated and then update the feedback image based on the filename
retrieved from the Content-Disposition header. This might not be possible
for certain platform because changing the drag meta-data might not be
allowed.
Re: [whatwg] Proposal to drag virtual file out of browser
Also, would it be possible to hook browser-produced data into this model,
so client-generated data (f ex text, html, pdf) could be dragged out as a
virtual file to the desktop?
You could also extend the File API to allow for user created instances of
FileData objects. This would be comparable to Java's Blob and Clob API.
Each blob could represent either a local file, http file, ftp file, in
memory data or lazy client-generated data. This is all unknown to the target
and it's very extensible.
Of course you could also create a data URL but you'd have to base64 encode
it and keep the whole file in memory.
The key to having a blob API is the lazy nature of it. Of course a blob
would only be living as long as the source document is still able to
generate the content on-demand.
(Here's some semi-relevant info on this pattern in the context of
DDDhttp://blog.calyptus.eu/seb/2009/03/large-object-storage-for-nhibernate-and-ddd-part-1-blobs-clobs-and-xlobs/
.)
I'm not sure I like this though because the complexity involved compared to
a DownloadURL-format. But there is a need to be able to do this with
client-generated data as well.
Sebastian Markbåge
On Tue, Aug 18, 2009 at 10:31 AM, Mike Wilson mike...@hotmail.com wrote:
Sounds interesting!
You only mention a singular file, what do you think about multiple files?
Also, would it be possible to hook browser-produced data into this model,
so client-generated data (f ex text, html, pdf) could be dragged out as a
virtual file to the desktop?
Best regards
Mike Wilson
--
*From:* whatwg-boun...@lists.whatwg.org [mailto:
whatwg-boun...@lists.whatwg.org] *On Behalf Of *Jian Li
*Sent:* den 18 augusti 2009 03:03
*To:* whatwg@lists.whatwg.org
*Subject:* [whatwg] Proposal to drag virtual file out of browser
SUMMARY
The HTML 5 spec defines the event-based drag-and-drop mechanism that could
cross the browser boundary. If a draggable element contains a URL, dragging
it out of the browser will only copy the URL value. However, in some
scenarios, we really want to download the data file from the specified URL,
instead of copying the value. Here we propose a way to allow dragging a
virtual file denoted by an URL out of the browser boundary.
USE CASES
In order to download the attachment from an Internet mail application, the
user will have to click the attachment link and a save dialog will pop up
to let the user select the destination folder. This will normally involves
multiple clicks. Native application, like Outlook, can let the user drag
attachments directly into the destination place, i.e. desktop, which is
really convenient.
WORKAROUNDS
Currently there is no direct support in HTML 5 to support such dragging of
the virtual file. To work around this, a plugin with such capability has to
be installed and used.
PROPOSAL
We propose adding a specific format string to the DataTransfer object:
DownloadURL. The data associated with the DownloadURL format should be
parsed similar to the URL format. When the drag ends in another
application, the remote file described in the associated data URL should be
downloaded and provided to the target application.
For example, here's how one can create a draggable image that results in a
file when dragged:
var dragTarget = document.createElement(img);
dragTarget.src = http://example.com/example-attachment.gif;;
document.body.insertBefore(dragTarget, document.body.firstChild);
dragTarget.addEventListener(dragstart, function(event) {
event.dataTransfer.setData(DownloadURL,
http://example.com/example-download-attachment;);
}, false);
Traditionally allowing the non-image file to be dragged out of the
browser is considered bad. The main danger here is that the user might
unknowingly drag a file that will auto-execute. To address this issue, the
browser needs to mark the dragged file to indicate that it is coming from
the Internet. With this zone marker, the user will be prompted with a
security warning dialog when the dropped file is launched. If a specific
platform does not support zone identifier marker, this feature should be
turned off by default.
We should consider allowing only http and https typed URL in the associated
data for the DownloadURL format. Should we further restrict the download
URL to the same origin?
If the filename is provided in the Content-Disposition header, it should
always be used. Otherwise, it is up to the browser to decide how the
filename is generated from the URL. But once it is chosen, it cannot be
changed.
The drag-and-drop feedback might be decorated with the filename and the
domain from which the file is downloaded. However, the real filename might
be only available when we initiate the download and get back the response
header. To address this, we can download the response header after the drag
is initiated and then update the feedback image based on the filename
retrieved from the
