describing browser capabilities (was: Content negotiation)

M. Hedlund writes:
 > At 10:03 AM 11/9/95, Shel Kaphan wrote (quoting me):
	...
 > >Are you saying that there is a universal repository
 > >of DTD's out there somewhere?   If you don't have the description, you
 > >have to get it *somewhere*, don't you?
	...
 > If you send _one_ URL that describes browser PopuBrowser's capabilities,
	[ ... bad things happen ... ]
 > One the other hand, if you send a document identifier,
	[ ... good things happen ... ]

I see what you mean now.  This is pretty close to what I suggested the
other day: there should be replicated databases, indexed by
HTTP_USER_AGENT string, that return *something* describing the
browser.  I agree that the DTD could and probably should be among
those things, but see no reason why it must be limited to that.
Returning a text document that describes, in simple terms, something
like the contents of 
<A HREF=http://objarts.com/cgi-bin/webmac.exe/browsercaps/index.html>
David Ornstein's Browser Caps database</A> for the browser in question
also seems potentially useful.  Nobody is required to use it -- only
people who really want to.  It's not pretty, it's not nice, it's just
something you need if you want to get this level of control.
It's a way to represent not just features, but bugs too. DTD's don't
do that.  Whether you wish to exercise this level of control is
between you and your library functions.

I am not at all sure I believe style sheets have much of a part in
this right now.  The reason is that the installed base of browsers
knows nothing about them.  This is not to knock style sheets at all --
it is just my view that a solution to this problem has to help in the
present world, not just "the glorious future".

 > >And no, I don't think any of this kind of information should be sent
 > >on every request.  I already proposed one method, using the existing
 > >Redirect machinery, for servers to "request" this information from clients.
 > 
 > Yeah, that would be a good idea if the info is coming from the browser.
 > But does it need to?
 > 
No -- it appears it shouldn't.  I disavow any previous comments to the
contrary. 
	...

 >         1. If you want to send _one_ page that just about anybody can read,
 > send HTML/2.0.  (This is no negotiation.)
 >         2. If you want to take advantage of HTML/3.0, send it only to those
 > browsers that include "text/html;version=3.0" in their Accept header.
 > (This is Internet Media Type negotiation.)
 >         3. If you want to take advantage of experimental tags and
 > particular versions of draft standards, get the browser's DTD and see if it
 > can render those tags.  (This is DTD negotiation.)
 >         4. If you want to influence the presentation of those tags, issue a
 > site-wide style sheet.  (This is one part of cascading style sheets (CSS);
 > some other parts include the user's own preferences, which aren't for you
 > to worry about.)
 >         5. If you want still-finer negotiation, write a page for every
 > browser about which you care.  (This is user-agent negotiation.)
 >         6. If you want absolute control, send PDF.  (This is no negotiation.)

 > Obviously, this structure is not in place today.  #1, #5, & #6 are not
 > protocol issues; nor are they desirable.  The rest need to be implemented
 > in order to work.  If they are implemented, I think this structure would be
 > a complete solution.
 > 

Seems entirely reasonable, except for what you said about 5.  
A case in point is the handling of multiple submit buttons.
It is entirely conceivable for a DTD to specify that a name field
occurs in this element, however the browser may fail to send that name.
It's a bug, but it needs to be represented somewhere, hopefully not by
a case statement for that browser in my code.

 > M. Hedlund <hedlund@best.com>
 > 
 > [1]<URL:http://www.w3.org/hypertext/WWW/Style/>.
 > 

Shel Kaphan
sjk@amazon.com

Received on Friday, 10 November 1995 17:16:46 UTC