[whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers
Mike Kelly
mike at mykanjo.co.uk
Mon Nov 17 13:44:56 PST 2008
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
More information about the whatwg
mailing list