Format Negociation in Practice [Was: Versioning HTML at the server]

Daniel W. Connolly (
Tue, 18 Oct 1994 11:25:32 -0500

In message <>, Chris Lilley, Computer Graphics U
nit writes:
>How should we serve HTML 3 to the Web? Is it still text/html ? Should
>the same URL point to two different versions using server-side trickery?

It would be great if we could hash this out once and for all, and
deploy the solution.

Format negociation is this nifty idea in theory, but in practice, we see:

"Click _here_ if you have a text-only browser."
"Click _here_ if you don't have a forms-capable browser."
"Click _here_ for postscript, _here_ for text..."

[First, I wish all the _here_'s would go away, but that's another
story altogether.]

I'd actually say that the Mcom extensions are less worrisome than tables:
if a document uses Mcom extensions, it still makes sense in existing
browsers. It looks like they were fairly careful about that.

On the other hand, if a server hands a table to a browser with no
table handling code, you get something like:

This table shows population growth: USA USSR 1000 3324
1985 1986

where the table contents gets streamed into the paragraph.

Ideally, the server would convert the table to PRE or some such.

But I don't think the technical details are the problem any more:
we have to make it easy for information providers to _use_ format

I don't know if this means more tutorial documentation, or some
http server configuration options, or changes to clients, or what.

I have a few ideas, but I'd like to hear from other folks: how can
we clean this mess up? Or is format negociation just not gonna work?

What can we do to avoid:

"Click _here_ if your browser doesn't support tables."
"Click _here_ if your browser doesn't support multilingual docs."
"Click _here_ if your browser doesn't support figures."
"Click _here_ if your browser doesn't support math."
"Click _here_ if your browser doesn't support stylesheets."