W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2011

[whatwg] a rel=attachment

From: Ian Fette <ifette@google.com>
Date: Thu, 14 Jul 2011 12:08:19 -0700
Message-ID: <CAF4kx8cSKqj+B0AWayhFchjFXiRDZeJBUY2Xg7ZKq6X-w29XAQ@mail.gmail.com>
On Thu, Jul 14, 2011 at 12:03 PM, Karl Dubost <karld at opera.com> wrote:

>
> Le 14 juil. 2011 ? 14:45, Ian Fette (????????) a ?crit :
> > 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).
>
> Which current websites?
>
> Take gmail as one example off the top of my head. If any of these files are
present as an attachment I get an option to view or download.



> > 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
> > should treat this link as if the response came with a
> content-disposition:
> > attachment header, and offer to download/save the file for the user.
>
>
>
> Are you then proposing to reverse the contextual click on the link to give
> the option, "view in the browser". All browsers have currently implemented
> "save this link as"?
>
> It may please some users. As a user, I will place this in the category of
> super annoying features. It then means I would need a preference in the
> browser to disable it.
>
> Then it is at least 3 modifications to implement it.
>


Not for all links, no, only links that have rel=attachment. And I would
assume that on such a link, yes, perhaps a "view inline" right click option
may make sense. I wouldn't expect this to be used on anywhere near a
majority of links, but an author can already try to craft a download link --
it's just that in many cases it's either requiring them to jump through
hoops or impossible (e.g. offline apps).


>
> --
> Karl Dubost - http://dev.opera.com/
> Developer Relations & Tools, Opera Software
>
>
Received on Thursday, 14 July 2011 12:08:19 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:34 UTC