W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2011

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

From: Bjartur Thorlacius <svartman95@gmail.com>
Date: Fri, 3 Jun 2011 15:46:49 +0000
Message-ID: <BANLkTikUxCj-GgAGNjm9MNA86EicXFaK9Q@mail.gmail.com>
On 6/3/11, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>    http://mysite.org/generate_progress_report.php?quarter=Q12010
> When saving, it would be good to use something like "Progress report of
> Q1 2010" as the filename.  But that's not "part of the URI" in any sense.
So you're suggesting using the title as the filename. In that case,
the <a> element has a @title attribute already.
<a href="http://mysite.org/generate_progress_report.php?quarter=Q12010"
title="Progress report of Q1 2010">progress report</a>

> Note that some browsers will do weird parsing of the query params to
> attempt to extract a "useful filename".  That seems strictly worse than
> just using Content-Disposition.
That's slightly better than just using the last non-empty path
component, though. But yes, in the general case, the filename should
be extracted from the title. Note that filenames being verbose by
default is a good thing (to avoid accidental collisions). The user can
provide short, easy-to-type filenames that he can remember himself.

> I strongly disagree.  I think browsers that use the Content-Disposition
> filename for "attachment" but not "inline" are just buggy and should be
> fixed.
FWIW MSIE9 seems to honor the filename hint with inline (contrary to
the test results mentioned earlier in the thread).

> Of course it sounds like your position is that they should not use the
> filename for "attachment" either... (in which case you disagree not only
> with me, but with most of the web).
... but agree with me. The filename hint is useful for providing
filename extensions. Honoring these irrespective of the Content-Type
is dangerous. I recommend browsers strip the first dot and all
following characters from filename hints - but then they could just as
well ignore it.
Received on Friday, 3 June 2011 08:46:49 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:33 UTC