“Right click and save as” needs to go away
svarden.se
svarden.se
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.
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.
It would be annoying too. If I want to open bunch of such links as background tabs then I would need to temporally change this setting and don't forget to return it.
From usability standpoint (ignoring security and performance considerations) it's better to show me content and save button simultaneously. Then why do it only when site author wants it? Saving images is common operation and it would be better to show save button for every non-dynamic content.
Why modern browsers don't have save button (https://upload.wikimedia.org/wikipedia/en/0/0f/Opera_3.62.pn... ) on toolbar by default and want users to use menus for such common operation? Because designers don't have a place to put it without reducing usability for most common scenarios of browser use. Also save button was not replacement for "Save as" in context menu.
Do we have solution for situation when application is complex enough that there is bunch of operations which are used rarely but must be easily accessible in one click and could be context-dependant?
Yes. Microsoft's Ribbon.
Google's quick view has saved me many times. But there really should be one simple and good solution for this problem.
https://addons.mozilla.org/en-us/firefox/addon/open-in-brows...
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.
However I have actually heard people complain about its yellowness when started without a document. I don't care Sumatra, keep it yellow.
Yellow is not an issue: https://code.google.com/p/sumatrapdf/wiki/CommandLineArgumen...
Another, less common, problem is erasing the URL in the process.
If you select "Open with..." instead of saving it, you don't have to. Honestly though I often find myself wishing I'd saved a copy later.
However, I would recommend re-downloading any pdf files instead of saving them from Chrome's reader, since I've encountered a couple that Chrome corrupted upon saving.
I'm actually happy with the way Chrome handles downloads in that it starts the download before you confirm if you want it, then deletes it should you decide you don't. It's cool clicking the "Download" link, navigating to the folder, renaming the file, and seeing the download is almost done.
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.
And actually quite some other applications do this (open as a temporary file) as well, it's a very common pattern: 7-Zip, FileZilla, to name a few.
And even if you didn't, there's always a temp directory that gets cleaned next reboot. Though I agree, the browser should take care of this, like most apps.
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.
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.
Every time I browse a site on an iDevice, yes.
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.
1. The formatting is more static. Papers and memos and other documents are created and intended to be artifacts, not just mutable information, and PDFs can preserve that better. In 10 years, the PDF will look more like it did originally than HTML in tomorrow's browsers.
2. They're more durable. As a self-contained document, they don't rely on externally served files such as JavaScript and CSS. Ideally most HTML files are capable of presenting their semantic content even when you strip all that away, but that's easy to get wrong (especially with the advent of client-side templating and JavaScript frameworks). It's easier to archive a PDF than a web page, just save it to a thumb drive and it's pretty much guaranteed to work.
3. It's every bit as future-proof as HTML. With multiple independent implementations of PDF viewers, many of which are open source, the format is not going away. It will be readable for years to come.
Different displays have different resolutions and different dimensions. That makes fixed layouts obnoxious to read on e-readers. The most obvious example of how fixed formatting is an abomination is a PDF on an ebook reader.
There is one reigning reason for having a fixed page layout: ability to cite pages, e.g. for academic citations.
There is no need to cite pages for works that have good digital versions, other than antiquated citation requirements (e.g. MLA/CMS). Ebook readers have text search. Cite a digital form of the work, and anyone with that work in digital form can find it... an exception being OCR'd pdfs and ebooks converted from PDFs, because OCR often screws up line breaks or has other errors that make searching unreliable.
For less-granular searching, there's section, table, and image numbering/labeling. Again, fixed layout is not required to make content searchable.
For text, only section in your "less-granular searching" would work, and not necessarily particularly well. Page number would often be more granular, and that's what's needed for paraphrasing - exactly where to find what you're discussing - but not exactly what it said.
A writer could also adopt page-neutral paragraph or sub-paragraph numbering. This is common, for instance, in classical texts (where such numbering has been done retrospectively, by scholars, because of the difficulties of citing passages with so many translations - the same general problem that paraphrasing has). To cite a few major examples, Plato's and Artistotle's works have such numbering, as does Hobbes' Leviathan.
Page numbering has poor granularity for citations in real scholarly work (where you'd ideally want to be able to cite within a few lines at most), and it prohibits flowed text. If someone has some case where they think they need page numbers for citations, they should figure out an alternative (a few of which have been outlined above).
My quarrel is with misapplications of PDF as a way of presenting regular old page content that would probably never get printed, stuff such as lists of contacts, FAQs, blog posts, etc.
I work with folks across a university who know how to make a PDF and embed a hyperlink into a page...and that's all they can do. Their content might be better off as a regular page, but it's a PDF because that's how they learned to upload content to a website in the absence of a CMS. I know, it's weird, but that's what I see on a day-to-day basis.
Does anyone know of a good resource that explains all the edge cases that must be handled?
The link is from http://stackoverflow.com/questions/93551/how-to-encode-the-f...
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...
When I was trying to implement a solution to this problem years ago, what I thought would take 20 minutes of coding, started to look like a week of research and testing, and I gave up.
But nowadays I'm so comfortable with just using the URL that the above encoding schemes just feel like unnecessary hassle. HTTP was designed to display the filename in plain sight in the URL, not bury it in a header. Use it as intended and even IE will happily comply.
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.
Lends itself reasonably well to a JS-only implementation, too:
http://jsfiddle.net/FLa8P/1/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.
Like "right-click and save-as"? I personally don't mind the small choice I get to make when downloading a file.
<a href="file.txt">File</a> (<a href="file.txt" download>Download</a>)
<a href="file.txt">File</a> <a href="file.txt" download class="download-icon" title="Download this file">Download this file</a>
[1] http://fortawesome.github.io/Font-Awesome/#icon/icon-downloa...
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).
Aye - another one of my pet peeves is "logo.png". WHICH logo!?
/fume
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.
Because both options are unacceptable.
If the server was in charge, then most websites would screw it up through incompetence or malice.
Two links for every link, or have the server (an entity who doesn't necessarily have the users interest in mind) having more control over what the user can do with the content it sends.
Both options suck.
To be fair? I got responses in favor of both options.
At least it's not Javascript.
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!).
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.
Just go to Options->General->Downloads, tick Always ask me where to download files
Internet Explorer also works like this practically eliminating step 1,2 and 4 from your scenario above.
However, it seems like a good candidate for a browser plugin for those who have fast connections and don't mind.
a[download]:after {
/* add an icon or something */
}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.
So, no clusterfuck. Anyhow you are right about the lag caused by downloading the whole file.
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.
https://addons.mozilla.org/en-US/firefox/addon/open-in-brows...
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".`
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
There's no way to make some pdfs "display" in the browser and others force download using these headers, correct?
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.
As a VDN (video delivery network) we're focused on 100MB - 8GB video files, so our clients' primary goal is to avoid ever having the file attempt to display in the browser unless as a media URL purposely supplied to an embedded player. In general a raw video file URL would be for a download, and forcing Content Disposition saves having to explain the "Right-click, Save As..." dance regardless of browser.
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.
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...
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.
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.
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.
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.
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?
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")
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.
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).
> 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)
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.
– Chrome, from version 14
– Firefox from version 20 (current)
– Android Browser from version 10 (current)
– Chrome for Android from version 25 (current).
(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?
There's nothing in there about disabling Save-As.
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.
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.
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.
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".
Also, as GavinB suggested for big .pdf and .jpg files, I would would prefer 2 choices,"save" and "view" buttons.
Example: <img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO 9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />
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. :)
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.
I dunno how I feel about forcing a download without a bit more clarity to the user.
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.
* 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.