On 2010-07-30 20:54, Eduard Pascual wrote:
On Fri, Jul 30, 2010 at 12:36 PM, Dennis Joachimsthaler<den...@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/
