[whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers

Hallvord R M Steen wrote:
>> as an example:
>> <a href="http://example.com/report">html report</a>
>> <a href="http://example.com/report" Accept="application/pdf">pdf report</a>
>> <a href="http://example.com/report" Accept="application/rss+xml">xml report</a>
>>     
>
> Sorry, both as an author and as a user I'd prefer this:
> <a href="http://example.com/report">html report</a>
> <a href="http://example.com/report.pdf">pdf report</a>
> <a href="http://example.com/report.xhtml">xml report</a>
>
> - Keep It Simple. For me as an author it's less typing, and for me as
> a computer-literate end user it's clear whether a link is going to
> make me wait for Acrobat loading or open directly - even if the link
> is taken out of the HTML context.
>   
"It's less typing" - Is that serious or are you joking?!

I disagree; it's no more clear to end users. There is no reason the 
status bar at the bottom couldn't say

http://example.com/report (PDF Document)

Trivial addition for browsers to take this information from the Accept 
attribute. If you put .pdf at the end a URL the server wont necessarily 
respond with a PDF content type, so any extra certainty you feel from 
that is artificial. It should be up for interpretation whether you chose 
to do it this way or not. At the moment HTML is not providing a way to 
take advantage of HTTP conneg, that's not very fair - particularly given 
the criticism that 'its not possible at the moment'. Surely a primary 
objective here must be allowing browser developers to make full use of 
every aspect of the HTTP protocol?
> On the other hand, I'd sort of like
>
> <a href="http://example.com/report" AcceptLanguage="no">Norwegian</a>
> <a href="http://example.com/report" AcceptLanguage="en">English</a>
>
> As the main problem with using content-negotiation for language right
> now is that you need to hard-link to actual files (i.e. file.en.html)
> to give users a way to "override" the negotiation on the fly. (No,
> nobody will reconfigure their browser to use your site and everyone
> must be given a choice of language even if they can't control the
> settings of the browser they happen to use.) It's not good enough
> though, since one would like the language choice to "stick"
> automatically - you still need to fall back to cookies and a custom
> script for handling language choice or "no suitable version" errors.
>
> Content negotiation is a lot nicer in theory than in practise..
>   
Well it's not nice in practice because HTML is currently flawed and 
insufficient as a way of telling browsers how to do it properly. This is 
entirely my point; let's make HTTP conneg possible in browsers by 
getting HTML right - and let the developers decide the best practices. 
By not supporting this part of the HTTP protocol (content negotiation) 
you are taking something fundamental out of the  hands of application 
developers (client and server side) because you don't think it's necessary.

The apparent resistance to this confuses me; since the solution is not 
complicated to implement, completely backwards compatible, and ignorable.

Regards,
Mike

Received on Monday, 17 November 2008 13:44:56 UTC