[whatwg] a rel=attachment
Ian Fette (イアンフェッティ)
ifette at google.com
Fri Jul 15 10:05:53 PDT 2011
On Fri, Jul 15, 2011 at 9:08 AM, Alexey Proskuryakov <ap at webkit.org> wrote:
> 14.07.2011, в 13:59, Tab Atkins Jr. написал(а):
> >> re-using the "enclosure" term from the Atom format (thus minimal
> > "enclosure" is a completely opaque name. I have no idea how it is
> > meant to refer to "download the linked resource instead of navigating
> > to it". If I think about it in terms of Atom I can *kinda* imagine
> > it, but it feels like a bad term there, and it would be an even worse
> > term in HTML.
> > A boolean @download attribute is much clearer and more direct. If
> > you're using @download to name the file as well, then adding a @rel
> > value is unneeded.
> What meaning will this attribute have on a platform that simply doesn't
> expose the notion of a file?
I would assume the platform would treat <a href="blah.php?id=123"
download="blah.pdf"> the same way as if it had followed a link to blah.php
and received a Content-Disposition: attachment; filename=blah.pdf header.
It's not introducing any new problems, and I would expect the behaviour to
> I think that this attribute could be quite confusing, and it will likely
> become more confusing with time, as more platforms arise that have creative
> ways of presenting data to users.
I agree we don't want to prevent creative UI in the future / platforms that
don't necessarily deal with files in the traditional way. However I don't
think this actually introduces any new problems, it just allows something
that can already be specified in server-side code to be specified in
> It also doesn't naturally help understanding that it's just poor man's
> Content-Disposition:attachment. From this point of view, I like Ian's
> original proposal (rel=attachment) more.
Yes and no - both are sort of a poor man's Content-Disposition :) The
question is whether we need to handle filename, and the proposal of
download=filename at least maps content-disposition fully and compactly.
> - WBR, Alexey Proskuryakov
More information about the whatwg