[whatwg] "Content-Disposition" property for <a> tags

[Roger Hågensen]

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/