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

On Fri, Jun 3, 2011 at 5:24 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 6/3/11 10:39 AM, Eduard Pascual wrote:
>>>
>>> ?http://mysite.org/generate_progress_report.php?quarter=Q12010
>>
>> Wouldn't that default (in the absence of a Content-disposition) to
>> "generate_progress_report.php" as the filename?
>
> Depends on the browser. ?But yes. ?And that's a crappy filename for the
> Q12010 report!
Well, that's a point we agree on: it's indeed a crappy filename. IMO,
this is a direct consequence of a crappy URI.

> Is it now? ?You have to do a redirect on the server side, increase latency
> for the user, etc. ?For what purpose, given that you just want to specify
> the filename and there is already a mechanism for that?
The better filename is just the smallest of the benefits provided by
the beautification. A semantic URI is an additional aid to navigation
and a noticeable boost to search engine visibility.

>> After all, if the author cares about having a reasonable filename, why
>> wouldn't they care about having a descriptive URI?
>
> Because the URI is generated based on a form the user fills out, and no one
> ever sees the actual URI?
For a typical snippet of client-side form validation, one or two extra
lines of JS can beautify in advance for a GET form. In the case of
POST, I would always use the PRG pattern, so the redirection comes
"for free". For a GET form with JS disabled, the actual redirection
happens, but this is now a fallback case that should only triggered on
a minority of the scenarios.

I'm not sure what do you mean by "no one ever sees the actual URI": I
work on a daily basis with half a dozen different browsers, and they
all display the URI wherever I navigate. In the case of FF, it won't
even let me open a window without a location bar unless the user
explicitly enables that through the "about:config" options. So I'd
rather say that most users actually see the URI.

Another question could be whether they _care_ about the URI. On one of
the sites I have worked in, we implemented a beautification system for
SEO purposes: the flow of 10-12 daily mails asking for help about the
site's structure dropped to 10-12 monthly (the navigation was not
perfect, but it wasn't horrible: it just was a rather complex site), a
few users mailing us thanking the change, and the visitor -> customer
conversion ratio for the site was doubled within a week.
>From that and some other cases (not so extreme, but in a similar
direction) I have reached the conclusion that users are more likely to
pay attention to the URI if it looks simple and clean.

> "better" byt what metric?
By the amount of things it achieves: besides setting the filename
(which I consider only a minor benefit), it improves navigation and
helps SEO (see comments above).

>> Actually, my position is more like "I don't care what the browser does
>> with this because I have no need to use it".
>
> That's great, and I'm happy you're willing to impose costs on your users so
> you don't have to use it. ?But others may wish to make different tradeoffs
> here.
Honestly, if this were coming from someone else, I'd take it as
trolling. But coming from you, I know that's extremely unlikely, so
I'll assume that there has been a misunderstanding at some point,
because that last statement is already taking things too far from
their context. So, please, let me summarize the whole thing, in a
(hopefully) clear way:
1) Most of my sites use some URI beautification techniques to aid both
user's and spider's navigation (with a significant effort to minimize
the impact on the users).
2) Because of (1), I haven't had any need to ever use the filename
argument on a Content-Disposition header: my beautified URIs already
serve as good enough filenames.
3) Because of (2), I do not hold a strong opinion about how that
argument should be handled on the many different scenarios.

Please accept my apologies if my earlier posts yielded a different
idea; the three points above are what I have been trying to express. I
think my English is rather good, but is not native and I may fail to
express my views and/or ideas from time to time.

I wouldn't ever mentioned this if Dennis Joachimsthaler hand't asked
about it on his reply to my initial post on this discussion, since I
don't think saying that I stay neutral on something contributes too
much to the discussion. I just stepped into the thread to share my
view about how to handle conflicts between HTTP headers and parameters
given on the markup; and this has turned into a nearly pointless side
discussion that doesn't contribute to the main topic. Feel free to
contact me privately or (if you think the discussion will be of
interest to other people here) to branch into a new thread if you want
to go on; but I'd prefer not to derail this thread any further.

Regards,
Eduard Pascual

Received on Friday, 3 June 2011 11:48:30 UTC