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

[Hallvord R M Steen]

>> 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?!

Isn't it? :)

> 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.

Not quite "trivial", since browsers to do what you ask would need to
maintain a table of "pretty" names for all MIME types - including
translating that table to all languages the UI is translated to...

On a more serious note: content negotiation is meant to automatically
choose a variant of a resource (format, language). However, in many
cases the variant is significant in a way that I as a user want
control over. The language and even format of a resource is actually
often essential to that resource's identity. (The whole
content-negotiation idea is based on that statement being false. I
believe it's true.).

I've built two-three websites that use content/language negotiation
and I now consider it an architectural mistake to rely on negotiation
because the URLs no longer uniquely identify the variants I in many
scenarios need to identify. It's OK-ish to do it as a pure format
choice where the server and UA just agree on using the PNG or GIF
version for an <IMG> tag. For links *users* (and FWIW search engines,
validators and other agents) may interact with it's however a big
mistake to move away from one URL per variant of a resource. In light
of my content negotiation experiments and experience I'd say an Access
attribute in HTML would be harmful to the usability of URLs.

As a URL user (web browsing human, HTML author, linker, bookmarker,
E-mail-with-links author) I often want to be sure about what variant
of a resource I link to. To be explicit about this across scenarios
requires explicit URLs with language and type information.

> 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.

File types are all about convention. It's useful when sites follow the
convention, and it's a surprise in the rare event when they don't.
Since most of the time they do it's more useful than harmful.

>> Content negotiation is a lot nicer in theory than in practise..
>>
>
> Well it's not nice in practice because HTML is currently flawed

After thinking about it I've concluded that it's not nice in practice
because the basic premise of content negotiation is fundamentally
flawed, namely that what variant of a resource users get from a URL is
insignificant and what's best for them can be determined
automatically.

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

My scepticism has nothing to do with whether it's easy to implement
(though I think you underestimate the required efforts - for example
the UA would need to verify that provided Accept: values are
correct/don't cause security problems etc.). My scepticism has nothing
to do with whether it is backwards compatible either. As a URL user I
just want to defend the usability of URLs against a theoretically more
pure but for practical purposes deeply flawed solution to a
non-problem.

-- 
Hallvord R. M. Steen