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

[Aryeh Gregor]

On Mon, Aug 2, 2010 at 12:21 PM, Michael Kozakewich
<mkozakewich at icosidodecahedron.com> wrote:
> People don't often like it when they're forced to do something. If they want
> to download it, they can select "Save Link As..." from their browser.

If the author can predict that the user probably wants to do this
(like because they just clicked on a button that says "Save"), they
should be able to trigger it directly.  This isn't to say that the
user must be *forced* to do it -- if authors use this annoyingly,
browsers will compete on providing UI to avoid the annoyance.  As with
anything UI-related in specs, it would just serve as a hint or
guideline, not an iron-clad command that all browsers must obey to the
letter.

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

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.

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.

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.