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

  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/

Received on Wednesday, 25 August 2010 22:15:10 UTC