On 2010-08-25 21:09, Ian Hickson wrote:
On Fri, 30 Jul 2010, Dennis Joachimsthaler 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).
It would also eliminate the need to handle such requests with a server
side scripting engine to change the headers dynamically to enforce
downloading of the content.
On Fri, 30 Jul 2010, Eduard Pascual wrote:
Let me complement the proposal with a use case:
http://stackoverflow.com/questions/3358209/triggering-a-file-download-without-any-server-request
This seems like a fine idea. I would recommend registering a new "rel"
type (marked as a "Hyperlink Annotation") and trying to get browsers to
implement it:
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
http://www.whatwg.org/specs/web-apps/current-work/complete/links.html#other-link-types
This is kinda ironic, I've asked for the same earlier here, and upon
looking at the WHATWG current work link there Ian,
I navigated to the http://wiki.whatwg.org/wiki/RelExtensions where I found:
"enclosure" described as "the destination of the hyperlink is intended
to be downloaded and cached" and it's marked as "proposed" currently.
And it links further to http://microformats.org/wiki/rel-enclosure which
was drafted in the summer of 2005.
And it's already in use in the wild (mostly Feed related but by the
looks of it elsewhere too).
May I suggest adding it to the specs? (after 5 years of proposed status
it's kinda time to decide right?)
Personally I'm gonna start using myself now as it seems some sites have
started using it for download urls, and I'll cross my fingers that
browsers will catch up.
Most browsers already support rel="enclosure" for RSS feeds so there
shouldn't be much work to support it for HTML(5) as well.
From the microformats site I quote the following:
"The value "enclosure" signifies that the IRI in the value of the href
attribute identifies a related resource which is potentially large in
size and might require special handling. For atom:link elements with
rel="enclosure", the length attribute SHOULD be" provided."
Most content that a web designer want to see the browser download fit
this criteria, and now that with HTML(5) that large content that are
intended to be streamed/played will be using the video and audio tags,
the rel="enclosure" will be relegated to mostly downloading (I'm sure
that RSS feeds will start to adopt the new video and audio tags in some
form later too.
So I only see it logical to re-purpose rel="enclosure" as a download
indicator.
The HTML specs could simply state that rel="enclosure" signifies that
the IRI in the value of the href attribute identifies a related resource
which is potentially large in size and might require special handling
and should default to a save UI or alternatively a save or open UI, and
that content intended to be streamed or played directly should use the
video and audio tags instead.
Heh, I can't believe I totally forgot that rel="enclosure" existed (for
over 5 years). *laughs*
--
Roger "Rescator" Hågensen.
Freelancer - http://EmSai.net/
