[whatwg] a rel=attachment

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
> bikeshedding)
> >
> > "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
be consistent.


>
> 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
client-side code.


> 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
>
>

Received on Friday, 15 July 2011 10:05:53 UTC