So the spec introduces a new attribute on
a-tags (so called “links” – this may be new to you ;-)) called
download (short: a@download – this technique of connecting attributes with tags is written up and documented by Mathias Bynens).
When you link to a file like an image or a PDF-document it will be displayed within the browser normally. The
download-attribute in links prevents this behavior and offers the file as a download in your browser.
The spec allows the attribute for having a value. This value can be a string which defines the name of the downloaded file. As a default the browser takes the file’s original name.
And this is what it could look like in HTML:
<a href="path/to/file/file.png" download="a-nice-image.png">Download this file</a>
The value of the
download-attribute overwrites the filename with
Content-Disposition-header can overwrite the name for the file.
This really nice demo exports a written text and offers it as download (but be aware of browser-support – see below).
The download-attribute is not supported very good at the moment of writing this article.
Chrome supports it since its version 14. Version 14 is only a view weeks away from the stable release.
Firefox 8alpha (Aurora-channel) does not support it as far as I experienced it. I did not find anything about any intensions when Mozilla will include it.
And the other ones? No support yet!
So, what’s the fallback?
There are other techniques to serve a file that will be offered as a downloads in the browser. For instance you can use an HTTP-Header that’s a mime-type that the browser does not know.
Here is an example with PHP:
header('Content-Type: application/force-download'); header('Content-Disposition: attachment; filename="some-file-name.ext"');
You should then open the download in a new window or tab, or in an iframe to prevent any stupid browser-behavior.
More about this issue here.