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

[Dennis Joachimsthaler]

Am 03.06.2011, 15:16 Uhr, schrieb Eduard Pascual <herenvardo at gmail.com>:

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

Yes, this was only an example which just came to my mind, nothing
special.

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

Yes, I was trying to refer to the verbosity. There's no html attributes
with dashes in them as far as I know, except for "data-", which are user-
defined. This would kind of break the convention a little. I could think
about having "contentdispo" or some shortname like this, it would fit
"better" to what we currently have in html.



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

Again, html convention: Currently html only has one "statement" in every
attribute, except for things like events (which is javascript) and style
(which is also ANOTHER language: css).

Seems cleaner to me if we stay to the "standard" and not change the syntax
"rules".

Please tell me if I missed anything here!

> Regards,
> Eduard Pascual