There are already ways to force browsers to download using HTTP headers. The author says this is a "server-side solutions to front-end problem", okay.<p>But anyways, when pages use this already, it OFTEN pisses me off, when I want to look at a PDF in browser, but the web app/page is forcing me to save it to disk and then re-open it in another app.<p>What we _really_ need, that we _don't_ have a way to do right now -- is signal the browser to _prompt_ the user as to whether it should be saved or displayed in-browser. The browser could ignore unless it was capable of displaying in-browser of course. That's something we do not have any way of doing in a reliable way now with HTTP headers, and I wish html5 would add that, instead of duplicating a lesser feature which is both possible now, and frequently annoying.
One small nitpick: please please don't make all your files download with a single filename.<p>In the article it gives an example of "fixing" a hideous generated filename like "203759-fs3.pdf" to download as "invoice.pdf".<p>Yes this is a little nicer, but please be _even_ nicer and put other relevant info in the filename, "invoice-2013-01-01.pdf" is infinitely more useful to me.<p>Context: My bank forces statement downloads to all come out as "statement.csv" .... once you have a nice collection of "statement [43].pdf" files lying around you soon long for that hidious generated filename (or a semantically better one).
For everyone complaining that they don't want to be forced to download--just have two buttons:<p>March Invoice: View - Download<p>This is <i>much</i> clearer for the average user than a single link with hidden right click functionality. Currently clicking on a link you have no idea what you're going to get.
I HATE sites that force downloading! I often have a 50+ MBit/sec connection and want to be able to choose between having a PDF (e.g. a invoice - all I need is the amount and the bank data) render in the browser so I can discard it after using (here: wiring the money) and not having to do:<p>1) download it<p>2) open it<p>3) do what I want to do<p>4) delete the file (which requires me to open the download folder, locate the file and delete it).<p>If I forget step 4, I usually end up with a clusterfuck of a download directory (mine has 20 GB already in half a year, most of it is one-off downloads!).
Note that the "download" attribute is extremely useful when the href is a data or blob URI [1]. This allows you to construct the file that the user is going to get in Javascript, rather than server-side. For example, if you wanted to write an image-editing web app and didn't want to round-trip to the server to allow them to download a copy.<p><a href="https://en.wikipedia.org/wiki/Data_URI_scheme" rel="nofollow">https://en.wikipedia.org/wiki/Data_URI_scheme</a>
> <i>There are or course other ways of forcing file downloads, such as adding certain configuration to your .htaccess file, but I think server-side solutions to front-end problems should be avoided whenever possible.</i><p>I'd disagree with this being a "Front End" problem. You, serving the file, presumably have an idea what you want the user to do with the file. The .html page you propose editing is server side. The file being <i>served</i> is server side. The server configuration is server side. But most importantly, most browsers don't handle that attribute.<p>So I'd say what you want is the Content Disposition header, specifically, "Content Disposition: attachment". Set a header for the file type you want handled. But that's not enough on its own to cover most browsers in the wild.<p>Various browsers handle this header differently. Our CDN supports the following headers for files which <i>are</i> viewable directly in the browser. Using the appropriate header <i>will</i> prompt to Save As... even with a normal (left) click.<p>We recommend number 2 or number 8:<p><pre><code> 1. Content-Disposition: attachment
2. Content-Type: application/x-download
Content-Disposition: attachment
3. Content-Disposition: attachment
Content-Type: application/force-download
4. Pragma: no-cache
Expires: 0
Content-Type: application/force-download
Content-Transfer-Encoding: binary
5. Pragma: private
Cache-control: private, must-revalidate
Content-type: application/x-download
Content-Disposition: attachment
6. Content-Encoding: AuraganDownload
Content-Disposition: attachment
7. Pragma: public
Cache-Control: must-revalidate, post-check=0, pre-check=0
Content-Disposition: attachment
8. Content-type: application/octet-stream
Content-Disposition: attachment
</code></pre>
This list was gradually added to over the last 10 years. Besides number 2, our main recommendation, the others here are for various edge cases such as popular downloaders or varieties of corporate firewalls, proxy servers, and reverse proxy (edge) caches. I included them just in case you're battling one of those cases and want some other incantations to try.
What's with Chrome adding extensions to the filename? Is this behaviour specific to Chrome on Windows or standard across all platforms?<p>The world does not revolve around windows. File extensions are optional, not mandatory, in unix land. If the site says the file is named foobar, its name is foobar not foobar.txt.
<i>Firefox quirk<p>When specifying a value for the attribute, Firefox will not automatically give the file the correct file extension like Chrome does. [...]</i><p>I beg to differ. This is not a "quirk" and Chrome does not anything "correctly" that Firefox doesn't. From the HTML5 spec, regarding the "download" attribute:<p><i>"There are no restrictions on allowed values, but authors are cautioned that most file systems have limitations with regard to what punctuation is supported in file names, and user agents are</i> _likely_ <i>to adjust file names accordingly."</i> [1] (emphasis mine)<p>As we can see, the spec clearly does not require a browser to do anything to the filename given as download's value. And it seems that the only reason a browser should consider doing any kind of change -- according to the spec -- is if the underlying OS cannot handle a filename's syntax. I don't know if Windows still does that but e.g. DOS used to have a restriction that filesnames must be at most 8 characters, and end in a dot followed by a three letter extension.
Unix-derived operating system do not have the system, so if the OP is running on, say, on a Mac, there's no reason for Firefox to fiddle with the filename. It conforms to the standard.<p>Now, which behavior is more reasonable is a totally different question, of course...<p>[1] <a href="http://www.w3.org/html/wg/drafts/html/master/links.html#attr-hyperlink-download" rel="nofollow">http://www.w3.org/html/wg/drafts/html/master/links.html#attr...</a>
There's something of a conflict between "The download attribute is supported in Chrome 14+ and Firefox 20+" and "but I think server-side solutions to front-end problems should be avoided whenever possible."<p>The client-side solution sounds nice, but there's still likely a large percentage of your users for whom it won't work.<p>So instead of just a server-side solution, to do this nicely you have to have BOTH a server-side and client-side solution, for now. How is that good?<p>I suppose you could leave the default & old browser users to fend for themselves (in a manner of speaking), but sadly the folks who are downloading a different browser are mostly the same folks who understand how to right-click.<p>The ones that need a simple download link are the ones still using their default browser.
How would a web designer be able to choose my intention prematurely without a crystal ball?<p>Not to mention download support in browsers got WORSE over the years. All major browsers (but especially Google Chrome with its "never ask, just do it" UI attitude) need a good download manager. I strongly prefer "save as..." over the mess that the Chrome default download behaviour is.
Right click and save-as might be annoying but it's also a critical piece of our tinkering economy. I don't want to use a client that prohibits me from downloading the web unless it's specified as "permissible" by the author. This is a step in that direction.
This appears to be trying to solve a problem that doesn't exist with a solution that is more problematic than the problem it attempts to solve.<p>If my browser can handle pdfs, I probably want to view them using the browser[1].<p>If my browser can't handle pdfs, it will be forced to download them anyway.<p>If my browser can handle pdfs, but I want to save it/view it with another program, I can use right-click+save as.<p>By contrast, a pdf which I want to view in-browser, but which forces the browser to download it instead is just a nuisance. Even if there were a 'right-click+don't save it, just view it in browser', I don't know that I need to use it until I have tried clicking the link.<p>In general terms: You publish content on the web, I decide how I view it. Try to force my hand and you'll just annoy me into going elsewhere.<p>[1] If the browser supports pdfs by default, but I prefer to view them with somthing else, there are usually settings to tell the browser how to handle different file types.
"There are or course other ways of forcing file downloads, such as adding certain configuration to your .htaccess file, but I think server-side solutions to front-end problems should be avoided whenever possible."<p>WOW. So http have the solution for that, but as you are lazy, you want to reinvent the wheel and do it on your own, forgetting that the fronting you are talking about is running over http.<p>The http header have a few years now (Content-Disposition). It is not related at all with apache (even if you mention a way to configure apache).<p>You give a service to the client, not just a pile of frontend. If you don't know how to do it, hire some people that knows how the webservers and http world works!. But what you are saying is that without understanding how http works, and without any interest on learning it, you want the world to change to your needs. Isn't it?
The PDF case is no problem with the builtin PDF support in Chrome and Firefox. Or if you like the Adobe stuff, just disable the plugin and you'll automatically get the download and then a prompt to launch Acrobat Reader.<p>This is similar to forcing links to open in new windows - assuming the user is stupid in a way that doesn't even let the user to revert to the normal web behaviour (no browser function to "open in same window" vs no browser function to "open in browser")
QWERTY keyboards need to go away, but they are design patterns that people are used to.<p><i>Any file the browser would normally try to display natively or through a plugin can be forced to download using this attribute.</i><p>What if you want to do the opposite? Are we going to have to do "Right+click and Open in Browser"? What about mobile? Also, as far as I'm aware this issue is only really with PDF files, as virtually every other MIME extension is not supported by a browser.
off-topic, but got to say it:<p>> lots of people are literally afraid of the right mouse button<p>...c'mon, when will people grow out of this? and by people I mean GUI designers! One of the reasons I hate the guts of Unity for example is that I can't simply 'right click' -> 'customize/properties/setting' on anything I want to change in the UI. I don't want to go to a 'control/settings panel' (that may not even have the options I care about) to change settings, I just want to go around and right click on things I want to tweak. Or if I want to invoke one of the alternate actions for an UI element. I know nowadays we are designing UIs for retards (pardon, 'cognitively overloaded busy people' is the term) and not power users, but this kind of hidden 'power user' functionality doesn't hinder 'average joe' in any way. <i>This is one of those things that old-school Microsoft UI design guys got right, but nobody gets it nowadays! (it can also be long-tap on touch screens or ctr-click on macs, but you need a universally known way of showing a menu connected to any UI element, a menu that also includes a shortcut to the particular preferences for it)</i>
Browsers that support the download attribute in HTML5 <a href="http://caniuse.com/#feat=download" rel="nofollow">http://caniuse.com/#feat=download</a><p>– Chrome, from version 14<p>– Firefox from version 20 (current)<p>– Android Browser from version 10 (current)<p>– Chrome for Android from version 25 (current).
Take a lesson from the user backlash that happens every time a browser removes a feature: Don't do that. The best you can do is encourage developers to use an alternative. The worst you can do is to force it on people who don't share your point of view.
Designers who think their site should behave differently from web standards need to go away. This is completely inappropriate for typical sites. It's only appropriate for web apps that really do deal with files.
Sure fine, as long as there's a "launch handler anyway" context menu option. I don't care what people think they need to say as long as I have a way of doing the things I want to do anyway.<p>Case in point: If I want to save a PDF I usually save it from within Okular. If Okular crashes while handling the PDF for display it's useless to me anyway.
I don't agree with the final point, "There are or course other ways of forcing file downloads, such as adding certain configuration to your .htaccess file, but I think server-side solutions to front-end problems should be avoided whenever possible."<p>If we are trying to FORCE a download, then this really is a server-side issue. If we want to give the user the choice, then it is a front-end issue.<p>The crux of the article is all about taking away the user's choice ... and so a server-side solution seems more reasonable per @jrochkind1.
I like this except for the last part where he mentions that he doesn't like server-side solutions to front-end problems. The way I see it, this <i>is</i> a server-side problem that only shows up on the front end. If we're talking about sending headers that tell the client to download something then that should be coming from the server. Now, it's awesomely convenient that HTML5 lets us do this but still, I see it as something that still "belongs" on the server side. Just my take on that last part.
Yuck, browser specific things? What about the browsers you didn't mention? I would prefer there to be one standard way, not complicated tricks to be set up for each browser.<p>My GF also hates to download files for viewing. Why I have to download this video, pdf, audio file, why I can't simply use it in the browser. I simply want to see the content, not to save the file permanenty on computer.
Doesn't this break the XHTML serialization?<p>IIRC, the HTML 5 `<elem attr>foo</elem>` is equivalent to its XHTML representation `<elem attr="attr">foo</elem>`. The implicit value of the attribute is duplicated in the attribute value.<p>In this case this would lead to `download="download"` as if the suggested filename is "download", not "use the filename found in the URL".
For people that want to test out the download attribute, instead of just reading about it, you try a demo here on your browser:
<a href="http://davidwalsh.name/demo/html5-download.php" rel="nofollow">http://davidwalsh.name/demo/html5-download.php</a><p>Also, as GavinB suggested for big .pdf and .jpg files, I would would prefer 2 choices,"save" and "view" buttons.
Does it also work for the Data URI Scheme, <a href="https://en.wikipedia.org/wiki/Data_URI_scheme#HTML" rel="nofollow">https://en.wikipedia.org/wiki/Data_URI_scheme#HTML</a><p>Example: <img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA
AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO
9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />
"Right click and save as" is the last thing to go away imo.<p>There are a LOT of things that need to go away first (to name a few: crappy development, obligatory js to view content, AWFUL prefixes (-o-, -webkit-, -whatever-) and of course browsers that suck your RAM like there's no tomorrow (yes, I'm talking about firefox and chrom{e,ium})).<p>But again, that's just me. :)
> Firefox quirk - When specifying a value for the attribute, Firefox will not automatically give the file the correct file extension like Chrome does.<p>I think the quirk is the other way around. I always dislike it when Chrome suddenly decices to add a ".txt" extension to the file I've just downloaded. It sometime even does this .js files.
What's really annoying to me is when links start downloading instead of opening the file in the browser. Is there any way to force Chrome to open a certain link, the way you can force it to download via "save as"?
"Right click" is meaningless to Mac laptops and every mobile device. For that reason alone, I dislike using the text "Right click to save."<p>I dunno how I feel about forcing a download without a bit more clarity to the user.