[whatwg] a rel=attachment

On Thu, Jul 14, 2011 at 13:46, Darin Fisher <darin at chromium.org> wrote:
>
>
> On Thu, Jul 14, 2011 at 1:32 PM, Tantek ?elik <tantek at cs.stanford.edu>
> wrote:
>>
>> 2011/7/14 Darin Fisher <darin at chromium.org>:
>> > On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard <glenn at zewt.org> wrote:
>> >
>> >> 2011/7/14 Ian Fette (????????) <ifette at google.com>
>> >>
>> >> > Many websites wish to offer a file for download, even though it could
>> >> > potentially be viewed inline (take images, PDFs, or word documents as
>> >> > an
>> >> > example). Traditionally the only way to achieve this is to set a
>> >> > content-disposition header. *However, sometimes it is not possible
>> >> > for
>> >> the
>> >> >
>> >>
>> >> This has been raised a couple times:
>> >>
>> >>
>> >> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html
>> >>
>> >>
>> >> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread
>> >> was derailed partway through)
>> >>
>> >> I've wanted this several times and I'm strongly in favor of it.
>> >>
>> >
>> > Yes, it seems very useful.
>>
>> Indeed, and has been pointed out, already specified (since 2005) and
>> implemented as well for HTML:
>>
>> http://microformats.org/wiki/rel-enclosure
>>
>> re-using the "enclosure" term from the Atom format (thus minimal
>> bikeshedding)
>>
>>
>> >> After mulling this over with some application developers who are trying
>> >> to
>> >> > use this functionality, it seems like adding a "rel" attribute to the
>> >> > <a>
>> >> > tag would be a straightforward, minimally invasive way to address
>> >> > this
>> >> use
>> >> > case. <a rel=attachment href=blah.pdf> would indicate that the
>> >> > browser
>> >> >
>> >>
>> >> This isn't enough; the filename needs to be overridable as well, as it
>> >> is
>> >> with Content-Disposition. ?My recommendation has been:
>> >>
>> >> <a href=image.jpg download>
>> >> <a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg
>> >> download=picture.jpg>
>> >>
>> >> where the first is equivalent to Content-Disposition: attachment, and
>> >> the
>> >> second is equivalent to Content-Disposition: attachment;
>> >> filename=picture.jpg.
>> >>
>> >>
>> > This is an interesting variation! ?I like that it addresses the issue of
>> > providing a name for the download. ?Using the term "download" here is
>> > also
>> > nice.
>>
>> Agreed.
>>
>> I've captured the suggestion on a brainstorming page:
>>
>> http://microformats.org/wiki/rel-enclosure-brainstorming
>>
>> Feel free to contribute or iterate.
>>
>> Thanks,
>>
>> Tantek
>>
>
> Why do you feel it is important to specify rel=enclosure in addition to the
> download attribute?
> Thanks,
> -Darin

Other way around.

rel="enclosure" is sufficient for today's use cases because authors
simply name the file accordingly on their server and then
implementations simply use the last segment of the URL as the filename
- presto 80/20 case solved (and solved 6 years ago with no
modification needed to HTML for it to be valid).

Having to specify a "download" attribute that reflects a filename
different from the last segment of the URL is the minority case, but
still sufficient to justify addition of the attribute.

Also the empty download attribute doesn't work as it is supposed to be
equivalent to download="download" which would simply name the file
"download" which is unlikely what author or user want.

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

Received on Thursday, 14 July 2011 13:52:11 UTC