Hacker News Reader

Comment by glenjamin | Hacker News Reader

Is there any way to make the browser do an Accept: application/csv header on a hyperlink?

I'm pretty sure users like their "Download as CSV" links, which I've generally done as /normal/resource/url(.csv)

While this post sets out the ideals, I think there are some cases where for usability, you have to do something less than ideal.

View on HN

They're ivory tower ideals.

The web has grown organically and it has the warts to prove it. It's useful to think about the spec and to work toward improvements, but if it's real world possible to have your services work well for mobile clients on m.domain.com and real world impractical to do so on your main domain (or any of the other examples regarding actions, languages, versioning, whatever)—then by all means, break the rules.

I think his main problem with the m.domain.com was redirecting to the main page. If it did a 303 See Other to the mobile version of the same article it wouldn't break the spec, as far as I can understand it.

Looking at the newer spec, we should be able to use "hreftype" for content type or "hreflang" for accept language: http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html#s_hyper...

I don't know if any browser will implement this or has implemented it, but in real world scenarios we'll probably have to stick with .csv and en/foo or ?locale=en for a couple of years...

XHTML2 is never coming. That train has left its station with HTML5. So long, elegance and ideals! At least I have my ruddy practicality here.

XHTML2 is dead, but the current HTML5 spec includes a 'type' attribute: http://www.w3.org/TR/html5/links.html#attr-hyperlink-type

> Is there any way to make the browser do an Accept: application/csv header on a hyperlink?

Sadly no. Browsers suck ungodly amounts of dicks in their handling (or absence thereof) of the Accept header. I don't know of any web browser with an even remotely useful behavior on that one.

Accept header is all but useless these days. Servers rarely look at the Accept header that is sent with the request, and browsers can rarely know ahead of time what type of content to expect when merely clicking on a URL. Check out this blog post by Eric Law on IE and the Accept Header (http://blogs.msdn.com/b/ieinternals/archive/2009/07/01/ie-an...)

It depends on whether you're doing a normal website or if it's (also?) a webservice. There are more HTTP clients besides browsers.

If you do use content type negotation, you are best off giving each type a different url (with the conneg doing a redirect) if the representations are usefully different ie you might want to bookmark one or the other.

In practise no one does use it, so just forget about it.

good point, as long as the browsers don't have convenient way of displaying you the possible displayable mime-types this function isn't very useful to the enduser.

Reply on news.ycombinator.com