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

[Eduard Pascual]

On Mon, Aug 2, 2010 at 7:37 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 8/2/10 1:15 PM, Aryeh Gregor wrote:
>>
>> If you don't agree that this use-case is worth adding the feature for,
>> do you think that:
>> 3) Something else?
>
> For the use case your describe, it might just make more sense for browsers
> to support Content-Disposition on data: URIs directly somehow...  Maybe.

I'd definitelly love that! :P
It would solve my use-case [1], and similar other cases.

Trying to sum up things:
Some applications use "save" buttons. While it may seem redundant with
the browser's ability to save the target of a link when the user
explicitly tells so; an in-page save button is still a clear
call-to-action.
Furthermore, some web-apps attempt to mimic the look-and-feel of
comparable desktop apps. There is a vast ammount of software that
performs some kind of saving; and to implement it on the web we
authors need some way to, at least, hint the browser that a resource
is being "navigated" as part of some in-page "save" UI element. The
way this is normally achieved is by round-tripping the server,
uploading (normally POSTing) the data for the server to send it back
with the "Content-Disposition" header. This is a workaround that
presents many issues:
- Prevents the application from working offline; even if everything
else on the app is purely HTML+CSS+JS-based.
- May cause significant delays when the volume of the data is large.
- It forces the data to take a trip around the world, creating a
security/privacy vulnerability that could be easily avoided with
client-based downloads (unless the server uses encryption, of course,
but encryption is expensive both CPU- and money- wise).
- It attaches network connection's unreliability to a feature that
would otherwise "just work".
- It may cause the bill to go to the clouds when using the app from a
pay-per-volume connection (such as those provided by many mobile phone
operators).

Of course, some people are worried about this being abused. And it's a
legitimate worry. Despite it may seem so, there is no need to _force_
a download. All we (authors) need is a way to _hint_ the browser that
a download is assumed/expected from the app's side. It's entirely up
to the browser (probably taking in account user preferences) how to
deal with such a hint.
Furthermore, I'm strongly convinced that in-page save buttons should
behave as closely as possible as Content-Disposition: attachment:
anything else would go against user's expectations (example: if a user
normally gets a Save/Open/Cancel dialog when accessing a zip file,
then any in-page feature to "save" a zip file should present the same
dialog).


Just my thoughts.

Regards,
Eduard Pascual