[webkit-dev] New feature: <a download=filename>

[Darin Fisher]

Hello WebKit!

I just wanted to inform the list that we are working to develop a new
feature that will enable web pages to force a navigation to act like it was
served with a "Content-Disposition: attachment" response header.

We want to solve several use cases:

1-  Support for initiating downloads from off-line applications.  Make it
possible to download a data, blob, or filesystem URL, and present the user
with a suggested filename for the download.

2-  Support for initiating downloads when you do not have easy control over
response headers.  For example, it may be a pain to configure a C-D header
server side.

3-  Related to #2, sometimes you want to have dynamic control over whether a
URL is served with a C-D header or not.  This typically involves adding a
query parameter to the URL (?download=true), but this means that you are
bloating web caches.

This feature is being discussed here:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-July/032431.html

As you can see this is something that has been discussed before.  There's
been a lot of prior interest in solving the use case.  Originally, we
thought a simple rel="attachment" would suffice, but it turns out that an
earlier proposal for <a download="filename"> seems to be gaining the most
traction.  (Unlike rel="attachment", @download gives the developer control
over the filename.)  At any rate, Mozilla seems to like the proposal (
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-July/032490.html),
and this feature is on track to be added to the HTML spec.

There are some open security concerns as this enables foo.com to force
resources from bar.com to be downloaded.  This issue is being discussed.

If you have input into the design of this feature, please follow-up with the
whatwg thread.  I just wanted to make sure that folks on webkit-dev were
aware of this work.

The WebKit bug is here:
https://bugs.webkit.org/show_bug.cgi?id=64580

Regards,
-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110720/e9be9e69/attachment.html>