- From: Roger Hågensen <rescator@emsai.net>
- Date: Sat, 31 Jul 2010 03:57:26 +0200
On 2010-07-30 20:54, Eduard Pascual wrote: > On Fri, Jul 30, 2010 at 12:36 PM, Dennis Joachimsthaler<dennis at efjot.de> wrote: > >> Having a Content-Disposition property on<a> tags which does the same as >> the HTTP Header. >> For example changing the file name of the file to be downloaded or rather >> have a image >> file download rather than it being shown in the browser directly. >> >> This would avoid constructs such as<a href="hi">Download</a> (Right click >> and click save >> target as... to download). >> > To top things up, note that "saving a file to disk" is always equally > or less dangerous than "letting the UA perform the default action for > a resource": on the most "evil" scenario, there would be at least one > further step of confirmation or user action before the saved data has > a chance to do anything (assuming it's in some executable form; > otherwise it will never "do" anything). > I really like this idea too as it has annoyed me when designing webpages as well. I'd propose the following though: <a href="stuff.zip" download>This defaults to application/octet-stream and clicking the link will behave as if the user selected Save As from UI context menu!</a> <a href="stuff.zip" download="audio/vorbis">This tells the browser this is audio and of type vorbis, clicking the link will behave as if the user selected Save As from UI context menu and the UI may default to the user's Music download folder!</a> The reason I suggest download="" is that it's flexible, it's for example possible to add to this in a compatible way by doing download="audio/vorbis;something else here" Where "something else here" could be "filename" or "modification-date" as per http://tools.ietf.org/html/rfc2183 This is somewhat important as it's possible that a file on a server could have a last modified that does not match reality (backup restoration failed to touch the modified date or the server is configured wrongly etc. or the file is served using a script), Example: <a href="stuff.zip" download="application/zip;filename=Stuff - Text Adventure Installer.zip">This defaults to application/octet-stream and clicking the link will behave as if the user selected Save As from UI context menu!</a> A little remark though, if download is used with something that is not a href then I'm not really sure, should this be a validation warning? Or should it be valid as long as some form of media is referenced, like for example: <image src="cool.png" download="image/png;Brand X's very cool logo.png">This tells the browser this is a image of type PNG, if the user triggers the Save As then the UI may default to the user's Images download folder, using the filename and modification date suggested by the download attribute! I'm also sure that web indexers like Google and the rest will love this as well, as they can make some early assumptions when scanning the html. There may no point for Google to bother with the .zip file for example, but the .png and possibly the ogg vorbis might be of interest and the modified date would also be of interest. There are other benefits to this as well, as it's possible to serve any content from a script it helps reduce ambiguity in cases where you today have got: <a href="stuff.php?id=15">Huh? I don't wanna guess what the filename will be or modified date<a/> or <a href="blah/stuff/">Good luck making any assumptions on this one, what would even the Save As browser UI look like for this?</a> So something like this certainly makes sense to me at least. How many here can recall at least once when you tried to download, and the filename matched the .php script rathr than the actual file that was downloaded? *raises hand and grins* PS! Obviously this does not excuse not having proper a proper Content-Disposition in the HTTP header as a server should provide that as well (preferably matching the download attribute exactly but if not then the download attribute takes priority in the Save As UI). Regards, Roger. -- Roger "Rescator" H?gensen. Freelancer - http://EmSai.net/
Received on Friday, 30 July 2010 18:57:26 UTC