“Right click and save as” needs to go away

http://svarden.se/blog/2013-04-22-right-click-and-save-as/

by cfj • 13 years ago

444 185 13 years ago

mschuster919• 13 years ago

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:

1) download it

2) open it

3) do what I want to do

4) delete the file (which requires me to open the download folder, locate the file and delete it).

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!).

btipling2• 13 years ago

Browsers (or site owners) could probably do a better job of differentiating links with download attributes. Maybe on mouse over show a little download cursor or something.

mschuster919• 13 years ago

In the "old times" Firefox asked me whether I wanted to download and then open, download into temp and then open, or download into a to-be-selected folder; with an addon I could force browse render as an option, too.

Yet, this required two mouse clicks in the "worst case" that the default selection didn't fit.

I think the best solution is: if no download attribute set and Content-Disposition is not "attachment", then render in the browser. If either condition is met, open a popup with large buttons immediately executing the action: download to default folder, download to temp (which will be deleted upon next browser start), download to specific folder, render in browser (if there's a registered handler plugin for this mimetype). Maybe add a checkbox "Open after download has finished", and maybe also add one "Try multi-stream download" (because many sites still limit single-stream bandwidth). Even more maybe, for video files add a "Preview with VLC" and fetch the required parts (header and final part of video) first, so I can stream and keep the file for later usage.

NathanKP• 13 years ago

To show an icon on hover over a link on the browser side it would require browsers to make an HTTP HEAD request for each link to see if it has the "Content-Disposition: Attachment" header. That would add a lot of overhead to the page load, so I don't think it would be added to any browser.

However, it seems like a good candidate for a browser plugin for those who have fast connections and don't mind.

jonahx• 13 years ago

1) I don't think your use case / preference is that common. I'd venture that most of the time a download is preferable; I know that's the case for me.

2) Even if I'm wrong about 1), it's hard to argue that there is never a good time to force a download, and so this is a useful feature to know about. I wasn't aware of it so appreciated the post.

sergiosgc2• 13 years ago

From the Firefox normal behaviour, I imagine it would ask you whether you wish to open the file in the OS registered handler or save it. If you tell it to use an external program, FF downloads to temp, not to the Downloads directory.

So, no clusterfuck. Anyhow you are right about the lag caused by downloading the whole file.

mschuster919• 13 years ago

The problem is that FF does not read the OS list of programs (or can call the "Use OS selection for program/Open With"), but has "its own source" - on Linux, this sucks, because if I want to specify an unknown program, it's most likely in /usr/bin, which has thousands of files and so blocks the disk for a huge time while reading the file list.

On Windows, it sucks too, because I have to go to c:\, then remember if the program is x64 or x86, then remember the producer of the program, hope the program files-directory is named after the producer or the software, and then find the correct .exe to open. SUUUUCKS.

thristian• 13 years ago

If you're using Firefox, you might be interested in the Open In Browser extension:

https://addons.mozilla.org/en-US/firefox/addon/open-in-brows...

mschuster919• 13 years ago

Yes, exactly this extension I talk about in another reply - but I don't use Firefox any more because it creates disk load and swaps heavily on a 5400rpm disk, and it locks up while waiting for disk i/o every ten seconds (every tab switch, in essence). Chrome's single-process-per-page model is better, because the OS can do proper swapping.

rmk22• 13 years ago

I don't know what OS you are using, but on linux, I save all of those files to /dev/shm. Since this parks it in shared memory, once I restart my computer at some point, they will be gone. The same can be done by using a tmpfs as your default download destination and a script that cleares any file older than x days etc. I basically use two download folders: ~/Dowloads/* and /dev/shm/; the first is being used for Downloads I'd like to keep, the latter for temporary files.

MereInterest• 13 years ago

Alternatively, use /tmp, since then you won't have the file unnecessarily using RAM until the next time you reboot.

tripzilch5• 13 years ago

Don't other browsers have a "temporary downloads" folder? For when you select "open this file with (...)" in the download dialog? Opera does.

Now I finally sort of understand why people like opening PDFs in browser plugins, I suppose ...

> 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!)

yeah well but that is your own fault for saving temporary downloads in a non /tmp directory. just put them somewhere where they'll get cleaned out every so often. this is a computer, you don't even have to take the trash out yourself, but it's still up to you to differentiate between "to discard" and "to keep".`

mschuster919• 13 years ago

Windows does not have a /tmp, and Chrome doesn't offer an easy(!) way to switch download locations per download.

cfj3• 13 years ago

I'm almost never on a 50+ MBit/sec connection, which brings up another point. When on a slow, data-capped connection, such as the one I'm on right now, I want to know the size of the file I'm downloading. That lets me decide if it's actually worth spending my precious bandwidth on. If not, I cancel the download. When letting the browser display the file there's no (easy) way of finding out the file size.

raimondious• 13 years ago

I forget step 4 too, which is why I have a cronjob that moves everything in Downloads to the Trash every day.

cjoh• 13 years ago

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.

afandian2• 13 years ago

Quite possibly, but that's not relevant to this article.

lukifer• 13 years ago

Settle down, no one's taking your right-click away. The author is just conveying that this is a bad default to force on users for the simple act of downloading.

If linking to a download, a simple click should do the job; meanwhile, power users should still able to right-click so as to pick the directory, etc.

obviouslygreen• 13 years ago

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.

Zirro• 13 years ago

He isn't saying that browsers should remove the "Save as..."-feature. However, he is suggesting that browsers and websites should implement the download-attribute, which he believes will make the need for "Save as..." go away in those cases.

jtheory2• 13 years ago

Further: the article is about browsers adding a feature for HTML5 developers that formerly required tinkering with HTTP headers on the server-side.

There's nothing in there about disabling Save-As.

GavinB• 13 years ago

For everyone complaining that they don't want to be forced to download--just have two buttons:

March Invoice: View - Download

This is much 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.

GhotiFish3• 13 years ago

so would the browser be enforcing that? Or the server?

Because both options are unacceptable.

jsingleton2• 13 years ago

I think the best way is for the designer to include both options. Don't leave it up to the browser.

DanBC• 13 years ago

The page author would be forcing it?

gcr• 13 years ago

Why are both unacceptable? Server enforcing downloading/viewing measn the user couldn't override its choice, but providing both links avoids that issue.

marcosdumay3• 13 years ago

The browser is enforcing that, unless you tell it not to, like you always can with a browser.

At least it's not Javascript.

cfj3• 13 years ago

Good idea, and one that more and more sites are implementing these days.

highwind• 13 years ago

Problem is that if the browser doesn't support viewing of the file, then both links will cause a download, which can be confusing to the user. I think we need a way to see if a MIME type of a file is supported by the browser (including its plugins.)

jrochkind14• 13 years ago

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.

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.

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.

Poyeyo• 13 years ago

I think Opera already does that.

jrochkind14• 13 years ago

Right, some browsers do, some don't. (I used to be able to _get_ Firefox to, with the right config, but stopped being abel to figure out how, then switched to chrome where i haven't figured out how either).

But what we need is a standard cross-browser way to request this behavior (prompt for download vs show), that by default standards-compliant browsers will comply with (I'll allow for users over-riding this default behavior with configuration, if the browser wants to support that, sure).

We don't have that. I wish html5 would add that, instead of minorly improving an annoying thing we already have (way to signal the browser to force or default to download).

Sure, it should be avail in the HTML not just in HTTP headers, so the browser can let the signal effect it's UI before it does an http request for the asset, sure.

Sami_Lehtinen3• 13 years ago

I really would love if Dolphin Browser and Opera Mini would open PDF files in browser. Downloading files for viewing and opening PDF reader really isn't nice option, when you simply want to have a quick look what the file is really about.

Google's quick view has saved me many times. But there really should be one simple and good solution for this problem.

hpaavola• 13 years ago

Yeah, isn't "Content-Disposition: attachment;" header exactly for this?

jsingleton2• 13 years ago

Content-Disposition can be very useful but it does have some potential security implications: http://www.gnucitizen.org/blog/content-disposition-hacking/

porges• 13 years ago

This way lets you do it for files hosted somewhere you don't have control of.

zokier• 13 years ago

Open in browser extension for Firefox might be somewhat close to what you'd want.

https://addons.mozilla.org/en-us/firefox/addon/open-in-brows...

raverbashing• 13 years ago

Which is funny, because I absolutely loathe opening in the browser, I prefer saving it.

Chrome and FF PDF viewers are better, but with Acrobat it was a bag of hurt.

Also, see: saving is the more generic answer. Save and you can see it, open it and before the Chrome 'save' button you had to re-download it.

jrochkind14• 13 years ago

If Chrome didn't offer any way to 'save as' a PDF that it was displaying (really?!?), that's clearly Chrome's problem.

TillE• 13 years ago

On Windows I've yet to see any PDF viewer that's faster or better than Sumatra. All the in-browser ones are a bit slow and lacking in features.

sspiff2• 13 years ago

I agree that the Acrobat plugin was a pain (and I always made sure to disable it in Firefox), but I absolutely love the Firefox in-browser PDF viewer. It doesn't lock up the PC while loading, and it has a convenient download button that doesn't seem to redownload the PDF when clicked (much like saving an already loaded image).

i_like_robots• 13 years ago

I'd also rather download and open in Sumatra but this is a handy feature I wasn't aware of. Opening the link in a new tab will not force the download (Chrome) unlike changing headers and masquerading the file as an application.

Camillo• 13 years ago

"Before the Chrome save button"? What does that even mean? Half the time I see people praising Chrome it's because of something thoroughly mundane, like an address bar, or saving files, or links. Did you guys browse the web using potatoes before you got Chrome, or what?

udp• 13 years ago

It's funny how many Windows users seem to think the PDF format is intrinsically slow, and all because of Acrobat Reader. Safari on OS X renders a PDF just as quickly as any other webpage, and always has.

tripzilch5• 13 years ago

> when I want to look at a PDF in browser

does that ever happen?

> but the web app/page is forcing me to save it to disk and then re-open it in another app.

because SumatraPDF actually loads faster than Adobe's browser plugin. Plus it's more secure, lacking all the weird scripting crud that shouldn't be in a document format anyway, smaller and open source. Only downside is that it can be really, really, really yellow.

drivebyacct2• 13 years ago

Adobe? Ha. I'll take Chrome or Pdf.js in Firefox, both of which are as fast or faster than the also fast Sumatra.

bjhoops1• 13 years ago

>> when I want to look at a PDF in browser > does that ever happen? I do this all the time. I hate downloading crap that I'm probably just going to glance at once then discard.

steveklabnik• 13 years ago

> does that ever happen?

Yes, I do this all the time. I read a _lot_, and I often don't want to save the file on my hard drive unless I'm going to refer to it again in the future. And if I do, I can just choose "Save" at that point.

rocky11382• 13 years ago

>> when I want to look at a PDF in browser > does that ever happen?

Yeah, I've done it a few times. It's handy when I know I'm not going to save the PDF for any length of time. Using Foxit Reader helps with this since it's a lot lighter than anything from Adobe.

pseudonym• 13 years ago

>does that ever happen?

Every time I browse a site on an iDevice, yes.

rzt2• 13 years ago

As long as people (mostly academia and research orgs) continue to publish their content exclusively in PDF form, then there will be a need to look at that content in a web browser.

I work at a university and it is amazing at how much content exists only as a PDF, even if it would be better suited as regular old HTML content. Trying to turn that ship around would also interfere with numerous business processes and entrenched ways of doing things.

I've tried to get people to stop with the PDF madness, but the admin who follows a publish process written down on a set of ten-year-old Post-It notes simply just does not get it.

jcampbell12• 13 years ago

Content-Disposition attachement is one of the hardest things to implement when you have UTF-8 filenames. You have to browser sniff, and even then I have haven't found a good solution.

Does anyone know of a good resource that explains all the edge cases that must be handled?

d0mine• 13 years ago

Here's some browser testing http://greenbytes.de/tech/tc2231/

The link is from http://stackoverflow.com/questions/93551/how-to-encode-the-f...

kijin2• 13 years ago

See [1] for a very comprehensive and up-to-date table of browser support for various encoding schemes. See [2] for browser-specific hacks.

Summary: most modern browsers including IE9 support RFC2231/5987. (Edit: see my other comment in this thread for IE6-8.)

Another option is to leave out the troublesome "filename" parameter altogether and use the last part of the URL to convey the same information, e.g. /files/uploads/2013/<file_id>/filename.ext. After all, most browsers already understand how percent-encoding works in the URL. With today's URL rewriting engines, this shouldn't be too difficult to achieve regardless of how your files are actually organized on disk or which language you use to perform access control. It would be as if the client were requesting a static file.

[1] http://greenbytes.de/tech/tc2231/

[2] http://stackoverflow.com/questions/7967079/special-character...

driverdan• 13 years ago

Mobile Chrome often gets this correct. For many file types it will ask what you want to do if you haven't set a default action. Just never set a default and it always asks.

marcosdumay3• 13 years ago

Isn't that exactly what browsers ask you when you click in "Save as"? Ok, it's not "display in browser", it's just "display" (or "open"), but what's the difference?

dspeyer2• 13 years ago

Generally the "open" option opens in some other app, not the browser. Including for formats the browser actually displays better.

Aardwolf• 13 years ago

I would love to have an option in the right click menu to IGNORE the HTTP headers. For example, sometimes there is a link to an image like a jpg or a png that then forces you to download it. It REFUSES to ever render it in your browser. A right click option to ignore all MIME types and show it based on extention or magic bytes in the file would be AWESOME. Why do no browsers have that?

chocolateboy• 13 years ago

As mentioned below, this is available in Firefox: http://spasche.net/openinbrowser/

andrethegiant• 13 years ago

I like the current method in Safari that opens PDFs in browser by default, but if I wast to save the PDF to disk, I just Option-click.

timrogers• 13 years ago

Agreed. Depending on context (of the content and myself!), sometimes I'll want to save and sometimes not.

A prompt from the browser would be the best option, but alternatively, I'd want the site to offer me an option as to how the external file should be handled. If the browser doesn't implement it, it says that the "Right click to save" nonsense could make sense.

wwweston• 13 years ago

That's a pretty good idea -- perhaps a "prompt" attribute instead of a "download" attribute.

Lends itself reasonably well to a JS-only implementation, too:

    http://jsfiddle.net/FLa8P/1/

jakerocheleau• 13 years ago

Awesome fiddle! Thanks for sharing that here, it's definitely a unique solution.

jrochkind14• 13 years ago

Nice, that JS is a great idea, thanks.

And of course it relies on the download attribute. So, okay, I guess the `download` attribute DOES make this possible with a bit of JS, where it wasn't before, okay, one step forward.

One nice feature of your solution is the user can still skip the prompt with a right-click or modifier-click 'save as' or 'open in new tab'.

Nicely done. I'm gonna use that in the future. To be more strictly legal, I'd use a `data-prompt="true"` attribute or something, instead of a not entirely legal made up 'prompt' attribute.

tomrod• 13 years ago

> 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

Like "right-click and save-as"? I personally don't mind the small choice I get to make when downloading a file.

mcgwiz• 13 years ago

Good point, but such a prompt would be similarly annoying (i.e. annoying to a similar number of users). The way I've done this in the past has been to provide two links, one of which triggered the inclusion of HTTP headers at the server, to trigger the Save dialo). Assuming the download attribute is supported, it's even easier:

  <a href="file.txt">File</a> (<a href="file.txt" download>Download</a>)

This could impact visual design in a negative way. A download icon[1] could be used instead.

  <a href="file.txt">File</a> <a href="file.txt" download class="download-icon" title="Download this file">Download this file</a>

CSS would be used render an icon and to make the text of .download-icon conveyable only in non-graphical browsers.

[1] http://fortawesome.github.io/Font-Awesome/#icon/icon-downloa...

malandrew• 13 years ago

The option approach with the ability to set a default is the best approach. Then depending on the default, the right click will show the non-default option.

vickytnz• 13 years ago

I moved to Chrome just to be able to see PDFs in browser. Lots of websites have info that way (restaurants are the worst) and I don't want to get it saved on my computer just to have to delete it!

smosher• 13 years ago

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.

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.

sergiosgc2• 13 years ago

What's with Chrome adding extensions to the filename? Is this behaviour specific to Chrome on Windows or standard across all platforms?

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.

mschuster919• 13 years ago

The problem is that Windows desktop market share is overwhelming and as a Website author, you have to think in Windows user terms!

nemetroid• 13 years ago

File extensions are optional in Windows. I haven't had this problem with Opera, FWIW.

chrisfarms• 13 years ago

One small nitpick: please please don't make all your files download with a single filename.

In the article it gives an example of "fixing" a hideous generated filename like "203759-fs3.pdf" to download as "invoice.pdf".

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.

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).

protomyth2• 13 years ago

Adding the business name in front of invoice-2013-... would be nice too.

noja• 13 years ago

Also the sha1sum of the document. Thanks.

camus• 13 years ago

that's definetly a very good idea. Customize your filenames with a relevant name , adding the date is a very good practice, and why not the user/customer name too ( for invoices,etc ... ).

skore• 13 years ago

> Yes this is a little nicer, but please be _even_ nicer and put other relevant info in the filename[...]

Aye - another one of my pet peeves is "logo.png". WHICH logo!?

vy8vWJlco• 13 years ago

2013-01-01-invoice.pdf sorts better for my purposes.

pseut• 13 years ago

yeah, but sorting files by date added is usually trivial, so I'd rather have the option of grouping all of the invoices together. But I completely agree that people should name these files to make sorting easier and more useful.

anigbrowl• 13 years ago

I could not agree more. Why, why, WHY don't people set metadata fields for PDFs (and other documents, but especially pdfs) and why don't websites use/require that metadata? We could be running a semantic web right now and be a year or two ahead of where we are if people would actually think more than one step ahead.

/fume

jtheory2• 13 years ago

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."

The client-side solution sounds nice, but there's still likely a large percentage of your users for whom it won't work.

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?

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.

The ones that need a simple download link are the ones still using their default browser.

mbesto• 13 years ago

QWERTY keyboards need to go away, but they are design patterns that people are used to.

Any file the browser would normally try to display natively or through a plugin can be forced to download using this attribute.

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.

marcosdumay3• 13 years ago

> 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.

It's worse with XML files, source code and some kinds of data files (generic separated by char). Browsers try to open those, and remove important data from the display (and the copy buffer).

fulafel• 13 years ago

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.

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")

Samuel_Michon• 13 years ago

Browsers that support the download attribute in HTML5 http://caniuse.com/#feat=download

– Chrome, from version 14

– Firefox from version 20 (current)

– Android Browser from version 10 (current)

– Chrome for Android from version 25 (current).

rivd• 13 years ago

and again... no IE.

(as the article mentions: work-around needed with conditional comments)

absolutely off-topic and yes a bit unreasonable, but after years of webdevelopment, i'm getting a little cranky at every mention of this "browser" that microsoft forces developers to put up with. Yes, i know this is a "new" html5 feature and that i cant expect corporations or consumers to keep in-house browsers up-to-date, but really: its a microsoft failure. Is it really _that_ hard to keep up with the competition?

foshur• 13 years ago

How would a web designer be able to choose my intention prematurely without a crystal ball?

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.

nextstep• 13 years ago

Does Mobile Safari support this download attribute?

bpatrianakos• 13 years ago

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 is 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.

mchanson• 13 years ago

Who was still using 'Right click and save as'?

Sami_Lehtinen3• 13 years ago

I am, with Security Now podcasts. I don't want to open those with VLC plugin which doesn't work too well.

stan_rogers• 13 years ago

I certainly do -- I almost always want to change the file name to something that makes sense at my end. I don't often care what makes sense at the creator's end; I want to find the file quickly when I need it.

dgesang2• 13 years ago

I do! Why?

* I just want to save the file, not view/open it.

* I can quickly determine where I want a file to be saved.

* I can rename the file instantly.

* Some files are huge, so I rather save than view.

* Bulk-Downloading many files at once.

Just because you don't need it in your daily work flow doesn't make it obsolete for everyone else.

renanbirck• 13 years ago

I do. I save files in the right place as soon as they are downloaded: that way you never have a messy Downloads folder or a crowded desktop.

cientifico• 13 years ago

"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."

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.

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).

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?

Cederfjard• 13 years ago

I'm not entirely sure that I've grasped all of what you're saying here, but the download attribute is in the WHATWG HTML specification, and can hardly be considered OP himself trying to reinvent the wheel.

ubersync• 13 years ago

Should I be surprised that it doesn't work in IE?

MRSallee• 13 years ago

"Right click" is meaningless to Mac laptops and every mobile device. For that reason alone, I dislike using the text "Right click to save."

I dunno how I feel about forcing a download without a bit more clarity to the user.

afandian2• 13 years ago

I'm on a Mac laptop and an Android phone and it's very meaningful to me. I think it's fairly well understood that "right-click" means "context menu". On the Mac I access the context menu by two-finger clicking or by holding ctrl when I click. On my Android mobile device I tap and hold.

Sami_Lehtinen3• 13 years ago

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.

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.

Terretta4• 13 years ago

> 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'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 served is server side. The server configuration is server side. But most importantly, most browsers don't handle that attribute.

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.

Various browsers handle this header differently. Our CDN supports the following headers for files which are viewable directly in the browser. Using the appropriate header will prompt to Save As... even with a normal (left) click.

We recommend number 2 or number 8:

    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

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.

cfj3• 13 years ago

I must admit my knowledge of content headers is lacking. Thanks for sharing your list.

teach2• 13 years ago

It's good to see such a comprehensive list, but these only help me if I want to configure download vs view on a per-filetype basis?

There's no way to make some pdfs "display" in the browser and others force download using these headers, correct?

Terretta4• 13 years ago

Dynamically select among these using a query string parameter in the link to the file.

DigitalTurk2• 13 years ago

> 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 served is server side. The server configuration is server side.

The problem is when you want to offer both a view and a download link. Your solution requires offering two different URLs for that, which also breaks caching in the case where a user first wants to view and then download the file.

Terretta4• 13 years ago

On the contrary, our solution as implemented on our CDN uses a query string parameter numbered 1 - 8 to select one of those sets which are then set by the server in the response. So you can choose it on the fly for any file.

rocky11382• 13 years ago

Control-click would work much better than this attribute.

mikecane• 13 years ago

Let's say that gets adopted everywhere. For people like me who are used to doing RC/SA, you'll have to put a "No Need To RC/SA" prompt. You can't win.

tomphoolery• 13 years ago

Wow, this is so useful and I never even knew it's been around. Thanks so much!

slacka• 13 years ago

For people that want to test out the download attribute, instead of just reading about it, you try a demo here on your browser: http://davidwalsh.name/demo/html5-download.php

Also, as GavinB suggested for big .pdf and .jpg files, I would would prefer 2 choices,"save" and "view" buttons.

Aloha• 13 years ago

No.

Sometimes I want to open the pdf in the browser, I often to not want to save it until I have been able to look at it and see if its what I want.

nnq• 13 years ago

off-topic, but got to say it:

> lots of people are literally afraid of the right mouse button

...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. 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)

Thrall2• 13 years ago

I think perhaps there is an increasing tendency to design one UI for every platform (touch screen tablets, desktops etc.) and to favour consistency across platforms rather than proper integration within each platform. So if right-click is difficult to emulate on a touch screen, then often the desktop version of a program available for touch-screen devices won't make good use of right-click either.

It is perhaps part of a larger trend to try and solve UI problems for tablets and phones, then push the solutions back to the desktop, despite the fact the desktop didn't suffer from the problem they attempted to solve.

jbrooksuk• 13 years ago

No, no it doesn't. It's taken this long to ingrain in every single computer users brain how to do this. To change it now would be a nightmare.

kevinpet• 13 years ago

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.

puddinman13• 13 years ago

I was hoping that at least IE 8 would support a client side fix for this, but hey who would ever assume that IE would support something.

Thrall2• 13 years ago

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.

If my browser can handle pdfs, I probably want to view them using the browser[1].

If my browser can't handle pdfs, it will be forced to download them anyway.

If my browser can handle pdfs, but I want to save it/view it with another program, I can use right-click+save as.

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.

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.

[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.

rudiedirkx• 13 years ago

They're not the same... The user should have final control and without 'rightclick & save' they don't.

mitchell360• 13 years ago

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."

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.

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.

racl101• 13 years ago

Well, when all browsers support the HTML 5 download features then maybe the 'Right click and save as' can go away. Until then it stays.

ender7• 13 years ago

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.

https://en.wikipedia.org/wiki/Data_URI_scheme

notaddicted• 13 years ago

Yeah, this is useful. You can generate the URI in a click handler as well, so if you need to do some last minute assembly it still seems to work like a regular download link.

kleiba• 13 years ago

Firefox quirk

When specifying a value for the attribute, Firefox will not automatically give the file the correct file extension like Chrome does. [...]

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:

"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 _likely_ to adjust file names accordingly." [1] (emphasis mine)

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.

Now, which behavior is more reasonable is a totally different question, of course...

[1] http://www.w3.org/html/wg/drafts/html/master/links.html#attr...

shurcooL• 13 years ago

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"?

laurent123456• 13 years ago

> Firefox quirk - When specifying a value for the attribute, Firefox will not automatically give the file the correct file extension like Chrome does.

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.

eurleif• 13 years ago

If the files were being served with a text/plain MIME type, it's sensible behavior for Chrome to add .txt, and it's the site's fault for sending the wrong type info.

pow-tac• 13 years ago

Does it also work for the Data URI Scheme, https://en.wikipedia.org/wiki/Data_URI_scheme#HTML

Example: <img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO 9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />

gioele• 13 years ago

Doesn't this break the XHTML serialization?

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.

In this case this would lead to `download="download"` as if the suggested filename is "download", not "use the filename found in the URL".

Ideka• 13 years ago

The "Firefox quirk" sounds more like a Chrome quirk to me.

_cipher_• 13 years ago

"Right click and save as" is the last thing to go away imo.

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})).

But again, that's just me. :)

ninakix• 13 years ago

I think we decided the whole "open in a new window" thing is annoying? Why not just leave the decision to the users to decide?

“Right click and save as” needs to go away

Related Stories