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.
"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?
It means Chrome comes with a built-in pdf reader that, when you decide to save the file you're looking at, does not re-download it. This is significant when dealing with large files, and not a feature present in all competing products.
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.
It seems kind of silly that certain browsers download it again. Isn't it stored as temp data somewhere? They should only have to rename it.
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.
Netscape (IIRC) would do another GET (or POST!?) when doing a view-source, which NEVEREVER made sense to anyone I would demonstrate it it. I want to see the source of the page that's currently rendered, not the source of another POST request. That behaviour thankfully seems not to be present in any modern browsers.
I may be misremembering, but didn't NN also re-GET on RESIZE EVENTS? I'm sure there was a very clever reason for doing so, but it sure did piss me off at the time.
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).
It might have something to do with my PC (i7 x220) but I cannot stand the Firefox viewer for anything but plain text. I find it very lacking in terms of performance compared to a native pdf viewer. Everytime a somewhat complex pdf opens up (mostly formulas, few images), the fan begins to rev up significantly..
Firefox's reader is an improvement over Adobe's, sure, but that's like beating snail in a foot race. Go Firefox, you show'em Chrome! It's still not SumatraPDF, it's not Evince. Saving the file and having it auto-open these programs takes less time then waiting for the browsers PDF readers to kick in. Of course it could be better, but frankly, I'd rather things be more unix'y, not less.
A major problem with saving all pdf files to be opened in a separate program is having to delete the temporary files afterwards. That's not very unix-y.
Another, less common, problem is erasing the URL in the process.
There are other readers in Windows (besides Window's 8 built in metro (full-screen) reader). Ever hear of Foxit http://www.foxitsoftware.com/Secure_PDF_Reader/ ? Mush much faster than Adobe Arobat.
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.
I imagine if you were to test that then the PDF rendering would actually be significantly faster than HTML, since OS X's rendering is all PostScript under the covers.
I've been using Sumatra for a long time, but it's been supplanted by Firefox in most cases recently. Sumatra is great and lightweight though, and it uses a robust and open source rendering and parsing engine.
That's cause you aren't actually looking at a PDF, most likely. If you are actually looking at a PDF in Chrome's renderer you will definitely be able to save it.
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.
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?
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?
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.
Thanks. These days it looks like a reasonable solution is to just call the file "download.ext" for anything older than IE9.
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.
In my experience, IE6-8 can handle UTF-8 filenames if (1) the extension is alphanumeric; (2) you percent-encode the rest of the filename, making sure that whitespace is encoded as "%20" rather than "+"; and (3) you put the whole thing between double quotes. Use RFC2231 for all other browsers, although slightly older versions of Chrome and Safari might cause trouble from time to time.
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.
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.
The security implication in this case is not directly related to content-disposition. It could just as well be implemented using the download attribute. The gist of the attack is that it was possible to inject arbitrary javascript into an html file that was downloaded. After opening the file locally, the usual browser protections do not apply since it's a local file and the javascript can use this to escalate its privileges.
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:
> 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.
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.
>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).
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?
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.
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.
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?
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.
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!
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.
> 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.
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.
I set my default download location to /tmp, which on my OS is automatically cleaned up. If I want to keep something I move it to my home directory after looking at it. Otherwise, I can just forget about it.
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.
To be fair, there are a number of advantages to having content in PDF's rather than HTML. For example,
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.
PDF preserves layout whereas html doesn't (generally, although it can preserve layout somewhat if you specify one font, fix font sizes, and fix all dimensions), but that's a negative for PDFs.
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.
I think you're missing a key part of citing (at least for me), paraphrasing. When discussing sentiment or similar without quoting, you wouldn't know what to search for. It makes sense to give a page number to review and get more information on the source, without that you wouldn't know where to look. You'd have to read the entire source.
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.
If you're paraphrasing, then you could direct-quote a critical part of the text so that a reader knows what to search for.
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).
No, I totally agree with you on all those points –– and they definitely highlight the value of PDF as a format.
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.
>> 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.
>> 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.
OK yes I understand better now. I never realized that other browsers apparently don't offer the "open with default application" option in the download dialog, like Opera does.
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.
Default application, yes. A browser tab, no. When I just want to look at an image, firefox is largely preferable to gimp. When I have a bunch of pdfs, firefox tabs are easier to manage than evince windows.
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).
Could, but putting it at the end of the document would seem pretty normal given what a lot of users get when downloading stuff. I think url shortners and tublr image urls probably paved the way.
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.
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.
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 ... ).
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.
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.)
Why are both unacceptable? Server enforcing downloading/viewing measn the user couldn't override its choice, but providing both links avoids that issue.
If the browser presented both choices, it wouldn't be able to distinguish by situation, so either it would hide downloading inappropriately, or it would present it inappropriately.
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.
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!).
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.
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.
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.
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.
Note I said in case the download attribute is set on the link, in which case, no, it would not require any request, it just follows the instructions set in the HTML.
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".`
But rarely, applications do this. The only notable exceptions is Winrar temp-extractions and some installers. Most other products simply let their stuff rot in TEMP hell.
Actually there are two TEMPs, one Local Settings and one Roaming Settings TEMP. But unlike most linuxes, Windows doesn't clean them, and some applications even fuck up when you delete their temp-stuff.
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.
This is true, the cold startup takes longer in Chrome than in FF. But if you're short on RAM (I usually hit 2-3GB usage without a browser running) and the OS starts swapping when you open tabs (I have ~30-40 open regularly), then the difference appears.
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.
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.
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.
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.
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.
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.
> 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.
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.
> 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.
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.
Sorry, I was replying about different URLs, you're focused on the caching question. Yes, most browsers would retrieve again. That's the price you pay for having the same file be able to be viewed or able to force a download.
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.
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.
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...
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.
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.
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.
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.
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.
"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?
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.
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")
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.
> 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)
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.
(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?
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.
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.
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.
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."
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.
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.
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.
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".
"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})).
> 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.
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.
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"?
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.
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.
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.