Re: [whatwg] Page displayed during/after download (meta refresh downloads)
On Sat, 23 Jul 2011, Kornel Lesi�~Dski wrote: There is a design (anti)pattern related to file downloads: instead of linking to a file directly, websites use Download links pointing to a page with meta refresh=5; url=actual URL to download (or equivalent javascript) and Thank you! text or further instructions how to use downloaded file (e.g. install an application). * it's hard or impossible to see or copy URL of the file (to download with another application, share URL, check if file type is correct by looking at the filename) * Right-click and Save As on Download now links is unreliable and sometimes results in HTML downloaded * Thank you! pages saved in browsing sessions cause files to be re-downloaded every time browser is restarted * Extra pages and meta refresh cause unnecessary delays. Your download will start in 5 seconds is very annoying when download itself takes couple of seconds. I wish this could be replaced with something that doesn't break download links. I agree. There are a number of existing ways that this could be addressed today, e.g. a rel= value that causes a link to automatically be downloaded (would require browser support), or script that detects when the user has clicked on a link for a download and replaces the page with the thanks page without interrupting the download (could be done today, but isn't as simple as a refresh). I think in terms of use-cases it can be expressed as: 1. Show users immediate and very clear feedback that the download is starting, even if browser's standard download UI is very subtle or appears only after the download server responds. 2. Allow website to show additional information about the download, while the download is taking place. e.g. Instructions what to do with the file after it is downloaded. List of mirrors to use in case download is slow or fails. List of related products to upsell. a download and UI improvements in browsers might partially cover use case #1, but I don't see an easy solution to #2, and partial improvement might not be enough to replace meta refresh download pages. And I'm afraid that meta refresh also fulfils another case: 3. Make it harder for others to link directly to the file, force them to link to a branded landing page. I think cases #1 and #2 could be satisfied with something like: a post-download-href=url of page to navigate to when download starts And to satisfy all three cases (without breaking links), it needs to be done at HTTP level, by adding HTTP header (or multipart response? or attribute to Content-Disposition?) that causes both file download to start and a page to be displayed at the same time. This could be done today using Link: headers and a rel value. I recommend approaching browser vendors about this. I don't think we need changes to the spec to handle this today. I'm not sure pages would adopt a solution, either. It might be worth approaching high-profile sites that do this and asking them whether they're interested in doing it in a different way. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Page displayed during/after download (meta refresh downloads)
Þann fös 22.júl 2011 23:09, skrifaði Kornel Lesiński: 2. Allow website to show additional information about the download, while the download is taking place. And to satisfy all three cases (without breaking links), it needs to be done at HTTP level, by adding HTTP header (or multipart response? or attribute to Content-Disposition?) that causes both file download to start and a page to be displayed at the same time. Sending multiple responses in reply to a single request is generally useful, but seems hard to implement in a fashion compatible with HTTP pipelining clients. How about a JavaScript opening a new browsing context and navigating it to the additional metainformation when the user follows the link?
[whatwg] Page displayed during/after download (meta refresh downloads)
There is a design (anti)pattern related to file downloads: instead of linking to a file directly, websites use Download links pointing to a page with meta refresh=5; url=actual URL to download (or equivalent javascript) and Thank you! text or further instructions how to use downloaded file (e.g. install an application). Examples: http://get.adobe.com/flashplayer/completion/?installer=Flash_Player_10.3_for_Mac_OS_X_10.4_-_10.6_(Intel) http://sourceforge.net/projects/vlc/files/1.1.11/macosx/vlc-1.1.11.dmg/download http://www.opera.com/download/get.pl?id=33846thanks=truesub=true http://www.google.com/chrome/thankyou.html?hl=en-GBplatform=mac This is problematic, because: * it's hard or impossible to see or copy URL of the file (to download with another application, share URL, check if file type is correct by looking at the filename) * Right-click and Save As on Download now links is unreliable and sometimes results in HTML downloaded * Thank you! pages saved in browsing sessions cause files to be re-downloaded every time browser is restarted * Extra pages and meta refresh cause unnecessary delays. Your download will start in 5 seconds is very annoying when download itself takes couple of seconds. I wish this could be replaced with something that doesn't break download links. I think in terms of use-cases it can be expressed as: 1. Show users immediate and very clear feedback that the download is starting, even if browser's standard download UI is very subtle or appears only after the download server responds. 2. Allow website to show additional information about the download, while the download is taking place. e.g. Instructions what to do with the file after it is downloaded. List of mirrors to use in case download is slow or fails. List of related products to upsell. a download and UI improvements in browsers might partially cover use case #1, but I don't see an easy solution to #2, and partial improvement might not be enough to replace meta refresh download pages. And I'm afraid that meta refresh also fulfils another case: 3. Make it harder for others to link directly to the file, force them to link to a branded landing page. I think cases #1 and #2 could be satisfied with something like: a post-download-href=url of page to navigate to when download starts And to satisfy all three cases (without breaking links), it needs to be done at HTTP level, by adding HTTP header (or multipart response? or attribute to Content-Disposition?) that causes both file download to start and a page to be displayed at the same time. -- regards, Kornel Lesiński
