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

[Eduard Pascual]

On Fri, Jun 3, 2011 at 2:23 PM, Dennis Joachimsthaler <dennis at efjot.de> wrote:
>> This grants the ability for any content provider to use an explicit
>> "Content-Disposition: inline" HTTP header to effectively block
>> "download links" from arbitrary sources.
>
> True. Is it still so that some browsers ignore the "filename" part
> of a content-disposition if an "inline" disposition is used?

Ok, I have never even thought about using the "filename" argument with
an explicit "inline" disposition. When I am in control of the headers,
I find it easier to "fix" the filename with 301/302 redirects, and
also have the bonus of some control about how that should be cached...
In short, I think that responding with a 2xx code _and_ attempting to
change what's essentially part of the URI through other means is a
contradiction, and thus a mistake on the best case, or some attempt to
fool the browser into doing something it shouldn't do on the worst
case.
Because of that, I'm ok with whatever way the browser decides to
handle the contradiction. You can read my position about
error-handling on my earlier post some minutes ago.

>> Personally, on the case I'm most concerned about ("data:" URIs used
>> for "Save log" and similar functionalities), there is never a "true"
>> disposition header; so my use cases do not push towards any of the
>> options. What I have just written is what I feel is the most
>> reasonable approach (the provider of a resource should have some
>> control over it above an arbitrary third party).
>
> Data URIs would very well benefit from this attribute, in my opinion.
>
> This would also cater to the canvas lovers. Downloading something
> drawn on a canvas instantly? No problem! <a href="data:...."
> disposition="attachment" filename="canvas.png">Download me!</a>

Yep, these are the cases I am actually concerned about. But on these
scenarios there is no HTTP header involved, so it doesn't matter (for
them) what takes precedence.

> This is still one thing that has to be settled though.
>
> a) How do we call the attribute?

Is there any reason to _not_ call it 'content-disposition'?
Ok, there is one: verbosity. But, personally, I have no issue with
some verbosity if it helps making things blatantly explicit.
So many years of browser vendors reverse-engineering the error
handling in competing products have convinced me that being explicit
is a good thing.

> b) Do we include the "filename" part directly into the attribute
>   or do we create a SECOND attribute just for this?
>
> People have been posting several formats now. But I don't think we
> actually have *agreed* upon one of those.

What's wrong with using the same format as HTTP? I am not too strongly
attached to that format, but I see no point in making things different
from what we already have. As a minor advantage, implementors can
reuse (or copy-paste) some few lines of parsing code instead of
writting them again, since they already parse the header when they get
it on an HTTP response.

Regards,
Eduard Pascual