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

[Bjartur Thorlacius]

On Mon, 02 Aug 2010, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> On Mon, Aug 2, 2010 at 12:21 PM, Michael Kozakewich
> <mkozakewich at icosidodecahedron.com> wrote:
> > I see where you're coming from, but we try not to force users to do things.
> 
> Let's say you have an image editor, written using canvas and whatnot.
> You want to have similar UI to native image editors, and that includes
> a "Save" button (probably adorned with a little picture of a 3.5"
> floppy, which is amusing when you think about it).  Clicking the
> "Save" button should pop up a dialog like in a native app, asking you
> where to save it.  Currently this can be done, but you have to send a
> request to the server and get a Content-Disposition: attachment
> response.  Probably you have to do it in a hidden iframe so it doesn't
> navigate the whole page, etc.  The request is for some feature to do
> this without the rigamarole.
> 
OK, lets assume this is a worthy use case for a moment (it propably
is). How do we know that a entity body (in HTTP parlance) should be
saved to permament storage rather than presented to the user?

A) Per resource metadata:
	Some resource is inherently insuitable for immediate
	presentation. Metadata regarding this can be provided by e.g. the
	Content-Disposation header of RFC 2076 (MIME).
B) By media type:
	A UA may decide that a resources of certain media subtype
	cannot be immediately processed or presented to the user. Think
	application/octet-stream, executables and likely all subtypes
	not present in mailcap (or equivalent).
C) Context:
	Due to the context of the link, such as per link metadata.
	The straightforward solution is registering a JavaScript callback
	to the click event on the relevant <A> element. This though is
	highly problematic as the "click" event isn't always fired when a
	link is activated (thus possibly resulting in normal navigation to
	the destination), UAs currently don't restyle <A>s with listeners
	on click (nor any elements with attached listeners). A (or AREA)
	with @action, @method or @rel~=save would allow easy styling
	with CSS and ignoring.

> If you don't agree that this use-case is worth adding the feature for,
> do you think that:
> 
> 1) The status quo is fine: you should have to send a request to the
> server to implement a "Save" button.  Offline image-editing apps don't
> matter.  Probably not a popular attitude here.
> 
> 2) You (the app author) shouldn't even be able to do that.  You should
> have to say "Right-click and choose 'Save As'".  Except that of course
> this is less convenient for the user, it takes up more space in the
> UI, the option might not be named the same thing in all browsers, apps
> might want to make right-click do something else so that context menus
> don't work, there are plenty of platforms (like phones) where "right
> click" doesn't even make sense, and in general the web platform makes
> no UI guarantees at all.  So then we get multipage guides explaining
> how to do it in a handful of popular browsers, with images and
> step-by-step instructions like
> <http://www.wikihow.com/Clear-Your-Browser's-Cache>, and unpopular
> browser users get to figure it out themselves.
> 
IMO image-filled step-by-step guides should be replaced by scripts
(runnable by lusers and readable by techies). But that's another topic.

> 3) Something else?
> 
> All in all, this seems like a very straightforward, useful thing to
> ask for.  Yes, users can do it through browser UI, but that doesn't
> permit authors to present it in a consistent way, draw the user's
> attention to it, put it where the user will expect it in context, etc.
> It's very similar to print(): of course the user can just hit Ctrl-P,
> but some people are used to clicking "Print" buttons and will be
> puzzled and unhappy if they don't find one.
> 
If the browsers UI doesn't have a "Print" button where the user expects
one to be the UI is broken, not the document to be printed.

> Not everyone will try to think of alternative ways to perform a task
> when their initial expectation fails.  That's the point where a lot of
> people give up, or call their techy friends or relatives for help.
> Many people use computers by rote, and don't know what to do when the
> usual incantation fails.  Even for those of us who know better, it's
> can be more convenient if the application has more control, so they we
> don't *have* to manually click through menus when the app can do it
> for us.
True. That's why web pages should provide lots of semantic metadata to
applications that may use that data to make informed decisions. I propose
the "method" attribute on <link>, <a> and <area> that MUST contain
a case insensitive space-seperated list of methods. A list of valid
methods should be obtainable from the WHATWG wiki. Note in particular
that methods are not limited to HTTP methods and neet not alter the
retrieval or submission of resources, though they most certainly can.
Valid methods might include:
GET (retrieve resource without presenting it to the user), PUT (alter
or create, akin to comp(ose) in run-mailcap), HEAD (retrieve metadata
about resource), navigate (present the resource to the user).

It's not clear to me what daemonized user-agents should do with these hints.